This article is for IT managers and business-continuity stakeholders who have to put an RTO and an RPO into a document, and for engineers who are asked whether the current setup meets them. It explains what the two numbers mean, why they are routinely set wrongly, and how to check them against reality.
Two numbers, two different questions
Recovery time objective (RTO) is how long a service can be unavailable before the consequences become unacceptable to the business. It is a statement of tolerance, expressed as a duration, and it is measured from the moment the service is lost to the moment it is usable again.
Recovery point objective (RPO) is how much data loss the business can tolerate, expressed as a duration of lost work. An RPO of four hours means that, after recovery, the data may be up to four hours behind the moment of the failure and that this is acceptable.
The easiest way to keep them apart: RTO looks forward from the failure (“how long until it works?”), RPO looks backward from the failure (“how far back do we land?”). They are set independently. A service can tolerate a day of downtime but no data loss (an accounting ledger), or no downtime but a lot of data loss (a stateless public information page).
A related term you will meet is the maximum tolerable downtime, sometimes called maximum acceptable outage. It is the point at which the organisation’s survival or its obligations are at risk, and the RTO is meant to sit comfortably inside it. If your RTO equals your maximum tolerable downtime, you have no margin for the recovery being slower than planned, which it will be.
What the numbers are not
Two misreadings cause most of the damage.
RPO is not the backup interval. A nightly backup does not give you a 24-hour RPO as a matter of arithmetic; it gives you a worst case of at least 24 hours of loss, plus whatever delay exists before the backup is usable. Suppose a backup starts at 01:00 and finishes at 03:00, capturing the state as at 01:00. A failure at 00:50 the next day finds the newest usable backup is the previous night’s: you lose 23 hours 50 minutes. A failure at 02:30, while the new backup is still running, finds you in the same position. And if the most recent backup turns out to be corrupt, the effective restore point moves back another day. So an RPO is a promise that must be backed by a mechanism (more frequent backups, replication, log shipping) and by checking that the mechanism works.
RTO is not the restore time. The time to copy data back is one component. A full recovery also contains:
- Detecting the failure.
- Deciding that it is a disaster rather than an incident that will pass, and declaring it.
- Assembling people and finding the runbook and credentials.
- Provisioning somewhere to restore to.
- Transferring the data.
- Rebuilding: replaying logs, rebuilding indexes, starting services in order.
- Verifying the service works.
- Cutting traffic over (DNS changes, load balancer updates, caches expiring).
An organisation that measures only step 5 will quote an RTO a fraction of the real one.
Deriving the numbers from the business, not from the technology
The honest way to set an RTO and RPO is to ask the owner of the business process what happens as time passes, and write the answer down. Useful questions:
- If this service were unavailable for an hour, a day, a week, what would stop? What would the first visible damage be?
- Is there a manual workaround, and for how long can the business run on it?
- What is the oldest data we could recover and still carry on? Can we re-enter or recreate the last few hours of work from another source (emails, paper, upstream systems)?
- Are there contractual or regulatory deadlines attached to this service? (Find the actual clause or rule rather than relying on recollection of it.)
Cost is the other half of the conversation. Short RTOs and RPOs require standby capacity, replication and rehearsed staff, and the cost rises steeply as the numbers shrink. Present the owner with the options and their price: this is not about technology preference but about letting the business choose how much risk to buy back. The IT team’s job is to say what each target requires, not to pick the number.
Per service, record at least:
| Field | Example (illustrative values) |
|---|---|
| Service | Order processing |
| Business owner | Head of operations |
| RTO | 4 hours |
| RPO | 1 hour |
| Workaround while down | Phone orders taken on paper form |
| Dependencies | Directory, orders database, payment gateway connection |
| Mechanism for RPO | Hourly database log shipping to secondary site |
| Last measured recovery time | (blank until a drill measures it) |
| Last measured recovery point | (blank until a drill measures it) |
The values above are examples for the format, not recommendations. The last two rows are the important ones: a target with an empty “last measured” field is a hope.
Tiering
Setting individual numbers for every system is not practical. Group services into a small number of tiers, each with a target pair, and assign services to tiers. Four tiers is typical:
| Tier | Intent | Example RTO / RPO (illustrative) | Typical mechanism |
|---|---|---|---|
| 1 | Business stops without it | Hours / minutes | Replication or standby, rehearsed failover |
| 2 | Painful but survivable | Under a day / hours | Frequent backups, tested restore |
| 3 | Inconvenient | Days / a day | Nightly backups |
| 4 | Can wait or rebuild | A week or more / a week | Infrequent backups, rebuild from definitions |
Check the arithmetic of dependencies. A tier-1 application that depends on a tier-3 directory service has an effective tier of 3, because it cannot start without it. This is where tiering exercises generally find their first real problem. The dependency’s target must be at least as demanding as the dependent service’s.
A worked check
Say the stated target for the orders database is RTO 4 hours, RPO 1 hour, and the database is 600 GB. The backup is a nightly full plus hourly transaction-log archives.
- RPO check. Hourly logs imply a worst case of just over one hour, if the log archive job runs reliably and the archive location is as protected as the backups. Verify by restoring the full backup plus logs up to a chosen moment (point-in-time recovery) and confirming the newest restored transaction’s timestamp. If logs are only copied on the hour and the copy takes ten minutes, the worst case is 70 minutes, which fails the target.
- RTO check. Suppose measured throughput from the backup store is 150 MB/s. 600 GB is 600,000 MB, so 600,000 / 150 = 4,000 seconds, about 67 minutes of transfer. Add log replay (measure it; assume nothing), provisioning of the target, the verification checks, and the time to decide and mobilise. If each of those is 30 to 45 minutes, the total lands around 3.5 to 4 hours: inside the target on paper, with no margin. The finding is not “pass”, it is “pass with no margin, and sensitive to any delay in the unmeasured steps”. A drill is what turns those estimates into measurements.
Notice what changed between the estimate and the check: the check produced a list of things to measure. That list is the drill plan.
Verifying targets
Targets are verified by exercise, not by inspection. See restore testing for the mechanics of timing a restore and designing a recovery drill for running one end to end. In the record, distinguish:
- Stated: written down and agreed by the owner.
- Estimated: calculated from component figures but never run.
- Measured: observed in an exercise, with date, restore point and operator.
Each service’s entry should say which of these applies. When a measured figure exceeds the stated target, escalate it as a risk to the owner who set the target. Do not quietly edit the target to match, and do not hide the result. The owner may accept the risk, fund a faster mechanism, or relax the target; any of those is a legitimate decision and all of them are better than an unexamined number.
Common mistakes
- One number for everything. “Four hours” for the whole estate means the number is either too lax for the important services or too expensive for the rest.
- Copying a figure from a template or another organisation. A target means something only because a business owner agreed it for a specific service.
- Ignoring the people. If recovery depends on one engineer who is on leave, the real RTO includes finding them.
- Forgetting failback. Moving back to the primary after a failover is a second recovery with its own duration and data-synchronisation problem.
- Treating replication as a backup. Replication copies deletions and corruption promptly. It can meet a tight RPO for hardware failure and still offer no protection against a mistaken or malicious delete. Different failures need different mechanisms.
- Measuring on a day that doesn’t count. A restore tested on a quiet weekend with the whole team present is a best case.
What to do next
Pick one service and fill in the table above, leaving the “measured” rows blank. Then use the drill planner to turn that into an exercise plan; it asks whether your targets are stated or measured and adjusts what it suggests, though it cannot measure anything for you. Before the exercise, read recovery runbooks so that the steps you time are written down, and plan time to record results afterwards using the after-action review guide.