RTO and RPO in Practice

RTO (Recovery Time Objective) answers 'how long can this system be down before the business impact becomes unacceptable?' It's measured from the moment a disaster occurs to the moment the system is fully operational again. A payment processing system might have an RTO of minutes (every minute down is directly lost revenue and customer trust); an internal weekly reporting tool might have an RTO of a full day (annoying, but not urgent).

RPO (Recovery Point Objective) answers a different question: 'how much data can we afford to lose?' It's measured as a duration — an RPO of 1 hour means that if a disaster strikes, losing up to the last hour of data (anything written since the last successful backup/replication point) is an acceptable outcome. A financial transaction system typically needs a very low RPO (losing even a few minutes of transactions is a real problem); a system that only ingests daily batch data might tolerate a much higher RPO.

Crucially, RTO and RPO are independent dimensions — a system can have a strict RTO but a loose RPO (must come back online fast, but losing some recent data is acceptable) or vice versa (can take hours to recover, but zero data loss is non-negotiable) — and the actual DR strategy and technical implementation (how frequently backups run, how replication is configured, how failover is automated) must be designed around BOTH numbers together, not just one.