RTO and RPO
RTO and RPO are the two numbers that determine the shape of a recovery design. Setting them after the architecture is chosen is backwards.
Definitions
| Term | Meaning | Failure it addresses |
|---|---|---|
| RTO | Maximum acceptable time from outage to restored service | Availability |
| RPO | Maximum acceptable data loss, measured in time | Data integrity |
They are independent. A system can tolerate a long downtime but no data loss, or a short downtime but a small amount of loss.
Setting the objectives
Questions for the business
- What happens if this service is unavailable for one hour? For four? For a day?
- Which is worse — being down, or losing the last hour of transactions?
- What is the revenue or regulatory consequence of each?
- Is the impact the same at all times, or does it vary by season or time of day?
- Who has the authority to declare a disaster and accept the cost of recovery?
The answers usually reveal that different components need different targets. A catalogue needs a shorter RTO than an internal reporting service; a payments ledger needs a shorter RPO than a cache.
Tiering
| Tier | RTO | RPO | Example |
|---|---|---|---|
| Tier 1 — critical | ≤ 15 min | ≈ 0 | Checkout, payment capture |
| Tier 2 — important | ≤ 2 h | ≤ 15 min | Customer portal, account management |
| Tier 3 — standard | ≤ 8 h | ≤ 4 h | Reporting, admin tooling |
| Tier 4 — non-critical | ≤ 24 h | ≤ 24 h | Internal tools, batch analytics |
Tiering by component prevents the common error of applying the strictest target to everything, which makes the programme unaffordable and therefore unimplemented.
What each target implies
RPO
| RPO | Mechanism |
|---|---|
| Near zero | Synchronous replication or multi-region strongly consistent database |
| Seconds | Continuous replication (RDS cross-region replica, DynamoDB global tables) |
| Minutes | Frequent snapshots or transaction log shipping |
| Hours | Scheduled snapshots |
| Day | Daily backup |
RTO
| RTO | Mechanism |
|---|---|
| Near zero | Active-active; traffic shifts automatically |
| Minutes | Warm standby; scale up and repoint |
| Under an hour | Pilot light; provision compute, restore data, switch DNS |
| Hours | Backup and restore; rebuild infrastructure, restore, validate |
| Day | Backup and restore with manual provisioning |
Cost
The relationship is non-linear. Approximate relative cost:
RTO 24h ▏
RTO 8h ▎
RTO 4h ▍
RTO 2h ▌
RTO 1h ▋
RTO 15m ██
RTO 0 ██████
The step from two hours to fifteen minutes is an order-of-magnitude change in both infrastructure and operational effort. Make that explicit in the business case rather than silently pricing the stricter option.
Documenting the decision
| Field | Content |
|---|---|
| Component | The service or data store |
| Tier | 1–4 |
| Agreed RTO | Measured in hours or minutes |
| Agreed RPO | Measured in hours or minutes |
| Strategy | Backup and restore, pilot light, warm standby, active-active |
| Mechanism | The specific services and configuration |
| Test cadence | How often recovery is verified |
| Last test result | Date and measured time |
| Owner | Who is accountable |
| Business approver | Who accepted the target and its cost |
This table is the deliverable. An RTO that exists only in a slide is not an objective.
Validation
| Check | Method |
|---|---|
| RTO is achievable | Restore or failover drill with measured timing |
| RPO is achievable | Compare the recovery point timestamp with the incident time |
| Backups are usable | Restore into a clean environment and run smoke tests |
| Dependencies are covered | Restore test includes secrets, certificates, DNS and configuration |
| Alarms detect the failure | Induce the failure and confirm the alert fires |
Common mistakes
- Setting RTO to a round number without analysis. "Four hours" because it sounded reasonable, not because anything supports it.
- Ignoring the dependency chain. The database restores in 40 minutes; the service is down for four hours because the secret and DNS were not in the plan.
- Assuming Multi-AZ is DR. Multi-AZ handles an AZ failure, not a regional one or a logical data error.
- RPO measured from the backup schedule rather than from the replication lag. A snapshot every hour does not guarantee an RPO of one hour if the snapshot itself takes 40 minutes.
- Targets that are never tested. The first real test is the incident.
Reporting
| Report | Audience | Content |
|---|---|---|
| Recovery objectives | Business and delivery | The tier table with approvers |
| Test results | Delivery and security | Measured versus target per drill |
| Coverage | Leadership | Components with current test evidence versus without |