RTO and RPO: The Two Numbers That Actually Matter
Every continuity policy has an RTO and an RPO typed in bold somewhere around page four. Almost none of them have ever been tested against real infrastructure, which makes the number a hope wearing a business suit.
Open any business continuity policy and somewhere around page four there's a table. Left column: system name. Right column: RTO and RPO, usually in hours, often suspiciously round ones. Four hours. Fifteen minutes. Twenty-four hours. Someone in a meeting decided these numbers sounded responsible, typed them into a template, and closed the laptop. Nobody has touched them since.
Which is a shame, because underneath the compliance language, RTO and RPO are two of the more useful numbers an engineering team can pin down for itself, provided anyone bothers to check whether the infrastructure agrees with the policy document.
What the numbers describe
Recovery Time Objective answers a specific question: how long can a system stay dead before the damage becomes unacceptable. That's the threshold where an outage stops being an inconvenience and turns into a crisis for the business behind it. An internal wiki can probably survive a day offline before anyone outside the team notices. A checkout flow measures its tolerance in minutes, and plenty of businesses would argue for none at all.
Recovery Point Objective is the uglier cousin. It asks how much data you can afford to lose, measured in time since the last good copy you could restore from. An RPO of twenty-four hours sounds tidy until you do the arithmetic: if the outage hits at eleven at night, you restore from last night's backup, and everything typed since breakfast is gone. Permanently.
A stated RTO that has never been tested is not a commitment. Call it a guess wearing a number, filed away where nobody will ever check it. Four hours reads beautifully in a steering committee. Whether the team can fail over a stateful database and repoint DNS inside that window at three in the morning, with the one engineer who knows the runbook on a red-eye, is a completely different question. It deserves its own evidence.
What tighter numbers cost
Tightening either number costs money, in a fairly linear and unglamorous way. Moving from daily backups to hourly ones is cheap. Moving from an RPO of one hour to a real RPO of thirty seconds means synchronous replication across two data centers, a standby environment that mostly sits idle, and a latency tax on every write while the two sides agree with each other. Moving from an RTO of four hours to fifteen minutes means the failover has to be automated and rehearsed, because a person reading a runbook at 3 a.m. is not a fifteen-minute process, however good the runbook is.
Picture two systems in the same organization. An internal reporting dashboard gets an RTO of two days and an RPO of twenty-four hours, because worst case, someone reruns yesterday's numbers and nobody's paycheck is late. That means a nightly backup job and a quiet afternoon spent restoring it, total cost close to nothing. The checkout service next door gets an RTO of fifteen minutes and an RPO of thirty seconds, because every minute it stays down is measurable revenue walking toward a competitor. That number requires multi-region deployment with continuous replication, plus a failover that fires automatically instead of waiting for someone to wake up and approve it. Same organization, same policy template, two completely different budgets hiding behind two rows of a spreadsheet.
None of this argues against tight numbers. Some systems earn them. The point is that RTO and RPO are cost decisions dressed up as technical ones, and organizations that pick the number first and cost it out afterward tend to end up with a policy document describing an architecture they never built and cannot afford.
The saner order runs backward from that. Work out what an hour of downtime and an hour of lost data cost a given system. Price out what it takes to hit a couple of candidate numbers. Pick the one finance can defend out loud, build it, and then test it on a schedule the on-call engineer doesn't get advance warning about.
An RTO nobody has drilled isn't a target. That's a hope with a great uptime record, right up until the day it isn't.