RTO and RPO

RTO and RPO are two foundational metrics of a disaster recovery plan that translate business requirements into concrete technical targets. RTO (Recovery Time Objective) is the maximum acceptable time within which a service must be restored after an incident. RPO (Recovery Point Objective) is the maximum amount of data an organization can afford to lose, expressed as a window of time — for example "no more than 15 minutes of work".

How RTO and RPO differ

Although both are measured in units of time, they describe entirely different aspects of a failure. RPO looks backward: it tells you how far back before the outage the data can be recovered. If your RPO is one hour and the outage strikes at 14:00, you accept losing anything written after 13:00 — which means backups must run at least hourly. RTO looks forward: it is the window from the moment of failure to full service resumption. The lower the RTO, the faster a standby environment must come online, which usually means pre-provisioned, already-running hardware rather than restoring from scratch onto a bare machine.

Low values on either metric cost money. An RPO measured in seconds requires synchronous replication, while an RTO measured in minutes demands a high availability architecture with automatic failover. That is why the values are set per service, according to the cost of its downtime.

Practical application

A banking system may run at a near-zero RPO (every transaction replicated instantly) and an RTO of minutes. A company blog will happily tolerate a 24-hour RPO (a nightly backup) and an RTO of several hours. In practice RTO and RPO are written into SLAs and validated with regular recovery drills — a plan that has never been rehearsed usually fails on the day it is needed. A well-chosen mix of backups, snapshots and replication lets you reconcile realistic targets with a sensible budget, which is why a data protection strategy is a standing part of designing any server environment.