There are two numbers that define what your backups are actually worth, and most organizations can confidently state only one of them.
The one everyone knows is RPO — recovery point objective — how much data you can afford to lose, measured in time. A one-hour RPO means that in a disaster, you might lose up to an hour of data. People track this because it maps cleanly to backup frequency: back up hourly, lose at most an hour. It's concrete and easy to reason about.
The one that gets neglected is RTO — recovery time objective — how long it takes to get the system back. Not how much data you lose, but how long you're down. And RTO is the number that bites, because it's the one that determines whether a disaster is a bad afternoon or an event the business doesn't survive.
Why RTO gets neglected
RPO is a configuration setting. RTO is a measured reality, and measuring it is work nobody budgeted. You can set an RTO target on paper — "critical systems back within four hours" — but the real RTO is however long the restore actually takes, and that's only knowable by doing it. (See the restore drill nobody runs; this is the same discipline from a different angle.)
So RPO gets a number because it's easy, and RTO gets a hope because it's hard. "We back up every hour and we can restore within four hours" — the first half is verified by the backup schedule; the second half is an untested assumption that collapses the first time it meets reality.
What determines real RTO
The actual recovery time is the sum of a chain of steps, and most RTO estimates only count the first one:
- Detecting and declaring the disaster. The clock starts before anyone touches a restore — someone has to notice, confirm it's real, and decide to invoke recovery. This can eat hours by itself if the detection and decision process is unclear.
- The physical restore time. Moving the data back. This is the part people estimate, and even this is usually underestimated — large datasets restore far slower than people assume, and restore speed is often throttled by the slowest link in the chain (the backup target's read speed, the network, the target system's write speed).
- Bringing the system up. Restored data isn't a running service. The application has to start, dependencies have to be available, configuration has to be right, and the thing has to actually work — which can mean troubleshooting under pressure.
- The dependency chain. The critical system depends on authentication, DNS, a database, a license server — and if those aren't up yet, your system can't come up regardless of how fast its own restore went. RTO is gated by the slowest dependency, not the system itself.
- Verification. Before you call it recovered, you have to confirm it's genuinely working and the data is sound. That's time too.
Real RTO is the total of that chain. The paper estimate is usually just the restore-time link, which is why reality is routinely several times the target.
Why it's the number that bites
RPO failures are bounded and usually survivable. Lose an hour of data and it hurts, but the business continues — you re-enter the hour, you reconcile, you move on. Painful, rarely fatal.
RTO failures are unbounded in their business impact, because every hour of downtime compounds. A critical system down for the four-hour target is an incident. The same system down for thirty hours because the real RTO was never measured is a different category of event — lost revenue, missed obligations, customers gone, and in the worst cases a business that doesn't reopen. The data was all there, perfectly backed up, correct RPO. It just took so long to come back that the delay did the damage the data loss didn't.
That's the trap: a perfect RPO buys you nothing if the RTO is a disaster. You protected the data and lost the business to the clock.
Closing the gap
Treating RTO as a real engineering target rather than a paper hope:
- Measure it. The only honest RTO is one you've timed in a drill. Restore a critical system end to end — detection, restore, startup, dependencies, verification — and time the whole chain. The number you get is your real RTO. Compare it to your target; the gap is the finding.
- Map the dependency chain. Know what each critical system needs to come up, and the order. Discovering mid-disaster that your app can't start because its database isn't restored yet, which can't start because authentication is down, is how a four-hour target becomes a thirty-hour reality.
- Design for the RTO you need, not the one you hope for. If the business genuinely needs a system back in two hours, a restore process that takes twelve is a design failure, not a documentation error. Faster recovery (warm standbys, replication, pre-staged infrastructure) costs money — but it's the only thing that makes a tight RTO real, and the cost is tiny against the downtime it prevents.
- Tier your RTO by criticality. Not everything needs to come back in two hours. The critical revenue system and the internal wiki deserve different RTOs. Spend the fast-recovery money where the downtime actually hurts.
Everyone can tell you their retention policy. Ask instead how long it takes to get the most critical system back, and whether they've ever actually done it. The confident, measured answer is rare — and it's the one that tells you whether the next disaster is survivable. RPO decides how much you lose. RTO decides whether you make it back. Track them both, but respect the one that bites.