Glossary
RTO and RPO
Also: Recovery Time Objective · Recovery Point Objective
Two numbers for the bad day: how long recovery may take (RTO), and how much data may be lost in the process (RPO).
Both are business decisions, not technical ones. An hour of downtime costs something entirely different in an online shop than in an internal tool, and that determines how much protection is worth building.
Architecture follows from RTO and RPO, not the other way round: an RPO of zero means synchronous replication, and with it latency and cost. An RPO of four hours allows a simple backup procedure.
The clock on the RTO starts earlier than most people assume. It does not start when someone begins the recovery, it starts when the outage happens. In between sit detection, alerting, the on-call engineer dialling in, assessing the situation and the decision to trigger recovery at all. In practice that is the first thirty to sixty minutes, and it is the reason why a recovery that technically takes twenty minutes still breaks an RTO of one hour.
The equivalent subtlety for the RPO is the question of what "data loss" actually means for the business. An hour of lost orders is not a data problem but a customer problem, and depending on the business there may be a way back, for example when the payments are still on record at the provider and can be reconciled afterwards. That reconstructability changes the requirement considerably and is rarely considered when the values get set.
The values do not belong to "the system" as a blanket figure, they belong to each business process. In an online shop, order intake and reporting may well carry entirely different numbers, and that differentiation is the single largest cost lever there is: a redundant environment for everything costs a multiple of one built for the single process where it counts.
The pair of numbers leads directly to a tier. Backup with restore on demand costs the least and delivers hours to days. A cold standby image shortens that to hours. A small second system running alongside gets you to minutes or an hour. Two active environments deliver close to zero and cost roughly double to run, plus the complexity of holding data in two places.
What makes all of this worthless is the missing rehearsal. A recovery procedure that has never been carried out is a guess with a reference number.
How you notice it
- Target values exist but nobody has tested them.
- Backups run but have never been restored.
- The cost of an hour of downtime is unknown.
- There is one number for "the system", not one per process.
- Only one person knows how the recovery works.
Not to be confused with
- SLA
- A contractual promise to customers, usually availability as a percentage, with legal consequences. RTO and RPO are internal targets for the disaster case.
- High availability
- Protection against the failure of individual components during normal operation. RTO and RPO describe the case where that no longer holds.
- Backup
- A means, not an objective. A backup without a measured restore duration says nothing about the RTO.
When it fits
- Before designing the protection: the numbers determine the architecture.
- When a client or auditor asks about recovery times.
- After an incident, to reconcile expectation and reality.
- During a migration, because recovery paths change along the way.
When it does not
- As a blanket figure for the whole landscape: that leads to protecting everything to the strictest case and is the most expensive variant.
- As a number taken from a template, without knowing the cost of downtime.
How to approach it
- Estimate the cost of downtime per hourRevenue, penalties, rework, reputational fallout. Rough is enough. Without that number the discussion about effort cannot be decided.
- Set values per process, not per systemOrder intake, payment and reporting have different requirements. That differentiation is the largest cost lever.
- Count detection and decision into the budgetThe RTO starts at the outage, not when work begins. Who gets alerted how quickly, and who is allowed to trigger the recovery.
- Derive the tier from itBackup, cold standby, a small second system running alongside, or two active environments. The number determines the tier, not the wish.
- Rehearse in full, with a stopwatchAt production data volume and without the person who built it. The rehearsal exposes missing access, certificates and orders of operation.
- Hold the measured numbers against the targetsIf the measurement misses, either you invest or you correct the target. A target you demonstrably do not hold is worse than an honest one.
Frequently asked
How do I derive sensible RTO and RPO values?
From the cost of downtime, not from technology. Work out what an hour of standstill costs in revenue, penalties and rework. Only that number makes the question decidable whether synchronous replication is worth its price or an hourly backup suffices.
Why do we break the RTO although the restore is fast?
Because the clock starts at the outage, not when work begins. Detection, alerting, dialling in, assessing the situation and the decision to trigger recovery consume thirty to sixty minutes in practice. If you want to hold the deadline, shorten that span first, and that is usually cheaper than any technology.
How often should you rehearse the disaster case?
At least annually, and in addition after every larger change to data storage or infrastructure. It becomes meaningful once the person who built the procedure sits it out. A recovery only one person can carry out has no RTO while that person is on holiday.
Does a low RPO always require synchronous replication?
Not necessarily. Sometimes lost transactions can be reconstructed from another source, for example from the records of the payment provider or from incoming messages still sitting in the queue. That reconstructability is often considerably cheaper than synchronous replication and is almost always overlooked when the values get set.