RPO defines how much recent data the business can afford to lose. RTO defines how long a service can remain unavailable. These two decisions shape backup frequency, recovery design, infrastructure cost and the order in which systems should be restored.
Recovery point objective (RPO)
- An RPO of four hours means the business accepts up to four hours of data loss
- Shorter RPOs normally require more frequent protection or replication
- Different workloads should have different RPOs based on business impact
Recovery time objective (RTO)
- An RTO of two hours means the service should be restored within two hours of disruption
- The target must include infrastructure, application and validation time
- A target that has never been tested is only an assumption
How to set realistic targets
- Start with business impact, not the backup product
- Group workloads into recovery tiers
- Account for dependencies such as identity, DNS, storage and networking
- Test the full recovery path and record actual results
Questions to take into a recovery workshop
- Which service causes the greatest impact when unavailable?
- What is the latest usable data the business can accept?
- Who confirms that a restored service is ready?
- What manual process can bridge the recovery window?