Two acronyms sit at the centre of every serious disaster recovery conversation: RTO and RPO. Most organisations with any kind of DR provision will have encountered them. Fewer have a clear, tested, realistic picture of what their numbers actually are, and even fewer have genuinely aligned those numbers with what the business can tolerate.
This post explains what RTO and RPO mean in practice, where the gap typically appears, and why closing it matters more than most organisations realise.
What the Acronyms Actually Mean
Recovery Time Objective (RTO) is the maximum acceptable length of time your systems can be down following a failure. It answers the question: how long can the business operate without this system before the damage becomes unacceptable?
Recovery Point Objective (RPO) is the maximum acceptable amount of data loss, measured in time. It answers the question: if we restore from our most recent backup, how far back in time will we be? How much data are we prepared to lose?
These are business metrics, not technical ones. They should be driven by what the organisation actually needs, meaning the operational, financial, and reputational consequences of downtime or data loss are, and then translated into technical requirements that the infrastructure must meet.
That translation is where things usually go wrong.
The Three-Way Mismatch
In most organisations, there's a mismatch between three things that should be in alignment: what the business assumes, what the IT function believes, and what the infrastructure actually delivers.
What the business assumes tends to be optimistic and vague. Leadership often assumes that because backups exist, the organisation could recover "reasonably quickly" from a serious incident. What "reasonably quickly" means in hours or days is rarely examined.
What the IT function believes is often based on theoretical capability rather than demonstrated recovery. "We could restore from backup in four hours" is a belief, not a fact, unless it's been tested. Configuration drift, dependency changes, and untested recovery procedures mean the theoretical timeline is frequently wrong.
What the infrastructure actually delivers is the only number that matters, and it's the one that's most rarely known with precision. Without a tested recovery exercise against a realistic failure scenario, the actual RTO and RPO are unknown quantities.
The gap between these three is what creates exposure. An organisation might believe it can recover critical systems in four hours; its actual recovery time, against a realistic failure, might be two days.
Why Backup Is Not Enough
The most common misconception about DR is that having backups means having disaster recovery. It doesn't.
Backups address a specific problem: data loss. If you have a good backup, you can restore data to a point in time. But restoring data is only one part of recovery. You also need to:
- Restore the infrastructure the application runs on
- Restore the correct application version and configuration
- Restore integrations with other systems
- Validate that the restored system is functioning correctly
- Route traffic to the recovered environment
- Communicate with users and stakeholders throughout the process
Each of these steps takes time, requires planning, and can fail independently. Without a tested runbook that covers the full recovery process, not just the data restoration, your RTO is unknown.
There's also the question of backup integrity. Backups that have never been tested may not restore cleanly. Configuration drift means that a backup taken months ago may not match the current application dependencies. Discovering this during an actual incident is not a situation anyone wants to be in.
What a Realistic DR Posture Looks Like
Good disaster recovery starts with honest assessment of what you actually need. Not every system requires the same level of protection.
Tier 1 systems, those whose failure would cause immediate, significant business impact, warrant aggressive RTOs, potentially in the range of minutes to low single-digit hours. For these, active-active or active-passive architectures in AWS, with automated failover, may be appropriate.
Tier 2 systems, important but not immediately critical, might tolerate RTOs of several hours. These can typically be served by well-configured backup and restore procedures with a tested runbook.
Tier 3 systems, lower criticality, higher tolerance for downtime, may accept RTOs measured in days. The cost of over-engineering DR for these systems rarely makes sense.
The starting point is an honest conversation about which systems fall into which tier, what the business consequences of failure actually are, and what investment is proportionate to the risk.
Testing: The Part Most Organisations Skip
DR plans that aren't tested aren't plans. They're documentation.
A tested DR plan means you've run a recovery exercise, ideally against a realistic failure scenario and not just a controlled partial restoration, and you have documented evidence that you can meet your RTOs and RPOs. It means your team knows what to do, the runbook has been validated, the dependencies are understood, and the timings are based on observation rather than assumption.
Most organisations test their DR provisions infrequently or not at all. The reasons are understandable: tests disrupt operations, they require time and resource, and there's a reasonable anxiety about the test itself causing a problem. But the cost of discovering during an actual incident that your DR doesn't work as expected is far higher than the cost of a controlled test.
Regular testing, at least annually for critical systems and more frequently if there's significant infrastructure change, is the only way to know where you actually stand.
The Business Case for Getting This Right
For many businesses, the question of DR investment comes down to cost. DR infrastructure, particularly for low-RTOs on Tier 1 systems, costs money to build and maintain.
The right frame for that decision is: what does an hour of downtime cost? What does a day? What does data loss at a critical point cost, in customer trust, in regulatory exposure, in operational recovery effort?
For most organisations, the answers to those questions make the investment in proper DR provision look reasonable. The risk isn't theoretical. IT failures happen. Ransomware attacks happen. Human error happens. The question isn't whether you'll ever need your DR capability. It's whether it'll work when you do.