RTO and RPO
How long recovery may take, and how much data may be lost — the two numbers from which every disaster recovery design follows.
Definition
- RTO — recovery time objective: the maximum acceptable duration of the outage.
- RPO — recovery point objective: the maximum acceptable amount of data loss, expressed as time.
Both are business decisions. Engineering's job is to state what each level costs, not to choose.
How they drive architecture
RPO is the more architecturally determining of the two, because it dictates the replication strategy:
| RPO | Requires |
|---|---|
| Hours | Periodic backups |
| Minutes | Frequent snapshots or log shipping |
| Seconds | Continuous asynchronous replication |
| Zero | Synchronous replication, at the cost of write latency and availability |
An RPO of zero is qualitatively different from an RPO of one second. It requires a write to be acknowledged by a remote replica before commit, which imports the network round trip into every write and means an unreachable replica can block writes entirely unless quorum is configured to tolerate it. Organisations frequently ask for zero without being told that price.
The conversation that produces useful numbers
Do not ask "how much downtime is acceptable" — the answer is always zero. Ask about consequences:
- What happens to the business in the first hour? The first day?
- What is the manual workaround, and how long can it run?
- What data, if lost, cannot be reconstructed from another source? Payments usually cannot; a recommendation model usually can.
- Is there a regulatory or contractual floor?
The answers vary enormously by service, which is why a single estate-wide number is always wrong. A reporting system at four hours and a payment system at fifteen minutes is a coherent position.
The distinction people miss
RTO is not the failover time. It is the time from the incident starting to service being restored, which includes detection, decision, execution and verification. A failover that technically takes 90 seconds inside an RTO of 15 minutes leaves 13 minutes for someone to notice, decide, and get permission — and that is usually where the time actually goes.
Measuring RTO in a rehearsal, from the moment of injection rather than from the moment of the button press, is what makes the number real.
Failure scenarios
- RPO stated but not measured, so actual replication lag exceeds it silently.
- A backup strategy meeting RPO but not RTO, because restoring 40 TB takes eleven hours.
- Both numbers set at the estate level, so everything is either over-engineered or under-protected.
- Never rehearsed, so the numbers are aspirations.
Interview question
"A stakeholder asks for zero RPO. What do you tell them it costs, and what would you propose instead?"