The recovery time objective is a decision, not a setting
The recovery time objective says how long a system may be down before that becomes unacceptable. It is not a number that comes out of the technology: it comes from the business, and the technology is built to it afterwards.
Two numbers, two questions
They are usually named together and they measure different things. Confuse them and you buy the wrong solution.
Recovery time objective versus recovery point objective
The RTO is about time without a system. The RPO is about work you lose. Both cost money, and they cost it in different places.
- RTO: how long until it works againMeasured from the moment it goes wrong to the moment the user can carry on. Including the time it takes to decide that you are going to recover — the part every estimate forgets, and in practice often the longest.
- RPO: how much work may disappearThe distance between the last usable copy and the moment of the outage. An RPO of one night means a whole working day may have to be redone. For some systems that is fine; for order handling it usually is not.
- They push different buttonsA shorter RTO asks for readiness: an environment standing by, people who can switch. A shorter RPO asks for copying more often or continuously. You can choose them independently, and usually should.
- They apply per systemOne RTO for the whole organisation leads to over-investing where it is not needed and falling short where it is. The list may be short, but it is per system.
How to arrive at an RTO that holds
Four steps. The first is the only one that is not about IT, and it decides the rest.
Ask the process, not IT
What happens to the work when this system is gone: does it slow down, does it go manual, or does it stop. Only that third answer justifies a short RTO — and then it is usually easy to justify.
Work out what an hour of downtime does
Not as a generic figure but in your own units: orders not arriving, people waiting, deliveries shifting, commitments missed. That number makes the conversation about the cost of recovery suddenly short.
Measure what you achieve today
Restore one system to a separate environment once and put a clock on it. Nearly every first measurement disappoints, and it is the most useful number in the whole exercise — because it is the only one that is not an estimate.
Choose, and record what the choice costs
There is a gap between the desired and the measured RTO, and that gap either costs money or gets accepted. Both are valid answers; not writing it down is not, because then the choice only surfaces during the outage.
Why an RTO is missed in practice
Four causes we keep seeing, and none of them sit in the backup software.
- The clock started earlier than assumedDetection and decision-making count. If it takes an hour before someone realises this is serious and another hour before someone is allowed to decide, half of a four-hour RTO is gone before anything happens.
- The restore was never performedA backup that succeeds is not a restore that succeeds. Missing certificates, licences tied to hardware and outbound integrations only surface when you put it back.
- Wanting everything back at onceWithout an order, every system’s RTO becomes the RTO of the slowest one. An order agreed in advance removes the argument at the moment there is no time for it.
- Nobody was on dutyThe technology stood ready and the people did not. Anyone promising a short RTO should also say who delivers it on a Sunday morning — and that is exactly where an external party makes the difference.
Further reading
What this connects to.
Questions we get about this
The ones that come up most, answered briefly.
What does recovery time objective mean exactly?
The time that may pass between a system failing and the user being able to carry on. Including the time to notice something is wrong and to decide that you are going to recover — the part nearly every estimate forgets.
What is the difference between RTO and RPO?
The RTO looks forward: how long until it works again. The RPO looks back: how much work you lose, counted from the last usable copy. A shorter RTO asks for readiness, a shorter RPO for copying more often; you can choose them independently.
How do I know which RTO we achieve today?
By restoring one system to a separate environment and putting a clock on it. That is the only figure in the whole exercise that is not an estimate, and nearly every first measurement disappoints.
Measure what you achieve today?
Restore one system to a separate environment and let the clock run. That is the shortest route to an RTO that is not an estimate, and usually to the first surprise as well.
Practical IT knowledge in your inbox
New guides on management, security and the workplace, written by the people doing the work. No sales talk, and you can unsubscribe in one click.