Skip to main content
Disaster Recoverylesson 1 of 3 · 3 min read

RTO and RPO

Two numbers, measuring different things

Two numbers govern every disaster recovery conversation, and they measure different things.

Your recovery time objective is the most downtime you accept, from the moment disaster strikes to the moment users are served again. Your recovery point objective is the most data loss you accept, measured in time. An hour means everything written in the hour before disaster may be gone forever.

Treat them as independent dials. A system restored in five minutes from a nightly backup has a great recovery time and loses a day of data. A system replicating continuously into an undocumented manual recovery has exactly the reverse.

Move each dial with different machinery. Your data loss is bounded by how often data leaves the blast radius. Nightly dumps give you up to a day, and continuous log shipping to another region gets you to minutes. Synchronous cross-region replication approaches zero, at the price of latency on every single write.

Your recovery time is bounded by automation and by how warm your spare is. How fast can infrastructure exist, data be loaded, DNS point somewhere new, and, the part everyone forgets, how fast can a person decide to pull the trigger.

Neither number is yours to choose

Neither number is engineering's to choose. Your business knows what an hour of downtime costs in revenue and reputation, and what losing an hour of orders costs in cleanup and lawsuits. You know what each tier of protection costs to build and run.

Hold that negotiation before any incident, because it is the actual deliverable. Both directions of mismatch burn money: spending heavily on multi-region for an internal tool nobody needs before Monday, or discovering mid-incident that your payments platform really loses a day.

Expect different answers per system. Payments might justify losing nothing and recovering in minutes while your analytics warehouse happily lives with a day of each. Pricing them identically wastes money on one and under-protects the other.

the shape of it
Last good copy02:00 backupDisaster09:14Back online13:14UsersRPO: data lostRTO: downtimeoutage begins
step 1 of 2
RPO is the window of writes that never left the blast radius; RTO is the clock from disaster to recovery.

Worked example

Ingrid, the infrastructure lead at a B2B invoicing company, gets told by the CEO that the requirement is zero downtime and zero data loss. She comes back with a menu instead of an argument. Option one, current state: nightly dumps, roughly 24 hours of RPO and an untested RTO she estimates at a day, cost 300 dollars a month. Option two: continuous WAL archiving to another region plus a scripted, quarterly-drilled restore, RPO 5 minutes, RTO 4 hours, about 1,100 a month. Option three, warm standby in a second region: RPO under a minute, RTO 15 minutes, roughly 9,000 a month plus an engineer-quarter to build. The CEO looks at actual revenue per hour, picks option two in ten minutes, and the requirement is now written down where the next incident can be judged against it.