Skip to main content
Definition

RTO and RPO (Recovery Time Objective, Recovery Point Objective)

RTO (recovery time objective) and RPO (recovery point objective) are the two target values behind any recovery plan. RTO states how long a service may be unavailable; RPO states how much data loss, measured in time, is acceptable. Example: a single nightly backup at 11 pm means an RPO of up to 24 hours. Both values come from the business impact analysis done by the business units, not from technology — technology is then selected to meet them, not the other way round.

In detail

RTO and RPO (Recovery Time Objective, Recovery Point Objective) in practice

Between the target and reality sits the chosen protection technology. Rough orders of magnitude: a daily backup yields an RPO around 24 hours, hourly snapshots proportionally less, asynchronous replication lands in the minutes range, and synchronous mirroring approaches zero — but only over short distances, since every write waits for acknowledgement from the second site.

As a concrete reference point, Azure Site Recovery creates a crash-consistent recovery point every five minutes when replicating VMs; that interval is fixed and cannot be changed, while application-consistent points are possible at a minimum frequency of one hour and cost performance, because the application is briefly quiesced. RTO is often calculated as restore time alone.

Realistically it also covers detection and alerting, the decision to declare an emergency, provisioning of compute and network, consistency checks and business sign-off. An RTO therefore counts as proven only once it has been tested at least once under realistic conditions — the trailing zero in the 3-2-1-1-0 rule exists for exactly that: zero errors when the restore is verified.

Ransomware adds a third value that appears in no backup report: the most recent demonstrably clean recovery point. It can be considerably older than the newest technically available one, because attackers often move inside a network for weeks before encrypting. Planning on RPO alone misses that scenario entirely.