Two short acronyms decide how badly a disaster hurts your business, and most owners have never had them explained properly. RTO and RPO are the difference between an incident that costs you an afternoon and one that costs you a fortnight and some customers. The good news is that the ideas behind them are genuinely simple once someone strips out the jargon. This guide does exactly that, then shows you how to turn two honest answers into a recovery plan you can actually rely on.
Two questions every disaster boils down to
When something goes wrong - a server dies, ransomware hits, a flood takes out the office - recovery comes down to two questions. How quickly do we need to be working again? And how much recent work can we afford to lose? Everything in disaster recovery is really an answer to one of those two questions, and the acronyms are just shorthand for them.
RTO, the Recovery Time Objective, answers the first: the maximum time you can tolerate being down before it does serious damage. RPO, the Recovery Point Objective, answers the second: the maximum amount of recent data you can afford to lose, measured in time. Get clear on those two numbers for your business and most of the technical decisions follow naturally.
RTO: how long can you afford to be down?
Recovery Time Objective is about downtime. If your RTO is four hours, you are saying the business can cope with being offline for up to four hours, but beyond that the damage - lost sales, idle staff, missed deadlines, reputational harm - becomes unacceptable. It is a business judgement, not a technical one, and different parts of the business will have different answers.
A shorter RTO costs more, because being able to recover fast needs more standby capability, more automation and more testing. The mistake is to assume everything needs a near-instant RTO. Your order system might need to be back in an hour; the archive of finished projects might happily wait two days. Setting one blanket RTO for everything either overspends on the trivial or underspends on the critical.
- •RTO = the maximum downtime you can tolerate before it does real damage
- •It is a business decision about impact, not a technical setting
- •Shorter RTO costs more - fast recovery needs standby capability and testing
- •Set different RTOs for different systems; one blanket figure wastes money
RPO: how much recent work can you lose?
Recovery Point Objective is about data loss. It is set by how often you take a recoverable copy of your data. If you back up once a day overnight and a server fails at 4pm, you could lose almost a full day's work - so your RPO is about 24 hours. If losing a day of customer transactions would be a disaster, that gap is too wide and you need to capture changes far more often.
Like RTO, a tighter RPO costs more, because losing less means copying more frequently, sometimes continuously. And like RTO it varies by system: losing an hour of finance data might be serious while losing a day of an internal wiki is a shrug. The number that matters is how much work your people would have to redo, and how much of that is gone for good versus merely annoying.
Why backup alone is not disaster recovery
Here is the trap that catches businesses out: having backups is not the same as being able to recover. A backup is a copy of your data; disaster recovery is the whole tested ability to get the business running again, including the hardware to run on, the network, the order you bring things back, and the people who know what to do. Plenty of firms discover their backups are fine but recovery takes days they did not have.
This is also why an untested plan is barely a plan. A backup you have never tried to restore is a hope, not a safeguard, and the day of a real incident is the worst possible time to learn it does not work. Recovery deserves the same belt-and-braces thinking as your backups themselves - which is exactly the logic behind the 3-2-1 backup rule and keeping at least one copy that ransomware cannot reach, covered in immutable backup.
Turning two numbers into a plan
Putting it together is straightforward. List your systems, decide an RTO and RPO for each based on real business impact, then make sure the way you protect each one actually meets those targets - and prove it with a test restore. Where the gap between what you need and what you have is uncomfortable, that is precisely where to invest. The aim is no nasty surprises on the worst day.
Most businesses get most value from focusing tight targets on the handful of systems they truly cannot run without, and accepting looser ones elsewhere. If you would like help setting realistic figures and building a plan that meets them, our backup and disaster recovery service does exactly that, and our guide to choosing a UK disaster recovery provider goes a level deeper for when you bring in outside help.