RTO and RPO

RTO is the maximum acceptable downtime; RPO is the maximum acceptable data loss. Both turn recovery from an aspiration into a measurable design target.

reliability

Definition

Recovery time objective (RTO) is the maximum acceptable duration to restore a service after disruption; recovery point objective (RPO) is the maximum acceptable amount of data, measured in time, that may be lost. Together they set the budget for backup frequency, replication, and failover design.

Context and scope

RTO and RPO are agreed with the business per service, not chosen by infrastructure teams alone. They drive architecture and cost, since an RPO of zero requires synchronous replication while a 15-minute RPO may be met with log shipping.

Common misconceptions

RTO and RPO are the same as SLA and SLO
Lower RTO and RPO are always better regardless of cost
An RPO of zero guarantees no data loss in every failure mode

Anti-patterns

Setting one RTO and RPO for every system regardless of business impact
Promising targets without measuring restore and failover times
Choosing synchronous replication everywhere without accounting for latency

Related concepts

Authoritative source

https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html

Two clocks around a failure

last recoverable point      failure         service restored
        |                     |                   |
        |<------- RPO ------->|<------- RTO ----->|

RTO measures time to restore service; RPO measures acceptable data loss expressed as time. An RPO of five minutes means the recovery point may lag the failure by up to five minutes.

Setting targets

Start with business impact: revenue per hour, safety, contractual penalties. Tier services rather than applying one target everywhere. Then choose mechanisms: nightly snapshots for hours of RPO, log shipping for minutes, synchronous replication for near zero, automated failover for minutes of RTO, active/active for seconds. Measure real restore and failover times, because declared targets without measurements are wishes.

Trade-offs

Synchronous replication reduces RPO but adds write latency and can stall when a replica is slow. Automated failover lowers RTO but risks split brain without quorum. Every step toward zero costs money and operational complexity. A strict RPO may conflict with a strict RTO when restoring a large dataset quickly is impossible.

Concrete example

Checkout targets RTO one hour and RPO five minutes through streaming replication, automated promotion, and quarterly game days; a measured drill recovered in 38 minutes with 90 seconds of lag. The analytics warehouse targets RTO 24 hours and RPO 24 hours, so a nightly snapshot is enough. Both targets are documented, owned, and reviewed.

RTO is not uptime and RPO is not backup frequency, although backup frequency bounds RPO. Lower is not always better once cost is considered. Related concepts include Disaster Recovery, Backup and Restore, SLO, SLI, and SLA, and Error Budget.