RTO vs RPO Explained (2026): Downtime and Data Loss Targets

Understanding RTO and RPO: The Core Concepts

Recovery Time Objective (RTO) is the target maximum time a system or business process can be unavailable after an outage before the impact becomes unacceptable to the business. It's a ceiling on downtime, set by what the organisation decides it can tolerate — not by how fast the infrastructure happens to be.

Recovery Point Objective (RPO) is the target maximum amount of data loss a business can tolerate, typically expressed as the time back from the failure to the last valid recoverable point. Both figures are expressed in the same kind of units — seconds, minutes, hours, or days — but they measure completely different things, and mixing them up is the single most common error in recovery planning.

RTO vs RPO: Same Outage, Two Different Clocks

The clearest way to separate the two: RTO is measured forward from the disruption point, counting the minutes until service is restored. RPO is measured backward from that same disruption point, counting how far you have to rewind to find data you can actually trust.

AWS frames this well for cloud applications — RTO is how quickly an application must be available again after an outage, while RPO is operationalised as how old the data can be when the application is recovered. Put another way, RTO asks "how long were we down?" and RPO asks "how much did we lose?"

These are genuinely separate resilience questions and shouldn't be conflated. A plan can deliver a fast RTO — the service comes back online quickly — while still having a poor RPO, because the data it comes back with is hours old. Equally, a tight RPO with a slow RTO means the data is current but the business is offline for far longer than acceptable. A recovery design has to answer both questions, not just the one that's easier to solve.

Why These Are Business Decisions, Not IT Defaults

RTO and RPO are business continuity metrics, not purely technical ones. They need to be defined around the acceptable consequences of downtime and data loss for a specific process — not set as a single blanket number across every system because that's what the backup platform ships with.

For UK organisations, that means recovery objectives should come from operational tolerance, regulatory exposure, and the customer-impact window of a specific outage — not a generic industry rule of thumb. In regulated sectors, recovery objectives also need to be auditable and aligned with wider business continuity planning and data protection obligations, which is a strong argument for these targets being owned and signed off at board level rather than left buried in a backup job's configuration screen.

In practice this means a customer-facing transaction system will usually warrant a tighter target than an internal reporting archive — but the right number for each one comes from what actually happens to the business, its customers, and its regulatory position during that specific outage, not from a benchmark borrowed from a different industry or a different application.

A Worked Walkthrough: From Tolerance to Target

Consider a core system going down. If the last full backup ran 24 hours before the failure, the realised RPO is 24 hours — that's the age of the data now at risk, regardless of what anyone intended the target to be. This is the gap between a policy on paper and what actually happens in an outage.

Now compare that to a deliberately designed target. If the business defines a 15-minute RPO, capture points — backups or replication — must occur at least every 15 minutes; the last clean copy can never be more than 15 minutes old, so the capture interval has to be no longer than that. Meeting that starts with having enough recent, separate copies of data to restore from in the first place — see how to implement the 3-2-1 backup rule as the baseline most UK businesses should have before tightening intervals further.

On the RTO side, if the business sets a one-hour target, recovery has to complete within 60 minutes of the failure. Translating that into actual infrastructure means working backward from the target: which restore mechanism, failover process, and dependency order can realistically complete inside that window. A sizing exercise is the practical next step — use a tool to size your backup and DR solution against the target you've actually set, rather than the one the software assumes by default.

Technology Choices That Actually Move These Numbers in 2026

The disaster-recovery goal is always to minimise both RTO and RPO — but the trade-off is that lower targets typically require more expensive controls, such as replication or instant recovery, rather than simple backup-and-restore.

Backup-only architectures recover from periodic snapshots: cheaper to run, but both RTO and RPO are bound directly by how often backups happen and how long a full restore takes. Adding replication narrows the RPO window, because data is copied continuously or near-continuously instead of on a fixed schedule. Instant recovery and failover architectures narrow RTO instead, because a standby copy can be brought live without a lengthy restore process — tooling such as Veeam is generally evaluated on exactly this: how much it narrows the gap between the target and what's technically achievable.

None of this matters if the recovery point itself isn't trustworthy when you need it. It's worth understanding immutable backups as a control here — an RPO is only meaningful if the copy it points to hasn't been altered or corrupted, whether by hardware failure or by an attacker, between capture and restore.

The Cost-Benefit Question: What Tighter Targets Are Actually Worth

Every step toward a tighter RTO or RPO carries a cost — more infrastructure, more licensing, more operational complexity to run and test. The target itself should be tested against what an hour of downtime, or an hour of lost data, actually costs that specific business process, not against a generic industry assumption.

Before signing off a tighter target, it's worth modelling the actual cost of downtime and data loss for the process in question, and weighing that against the cost of the technology needed to hit the target — you can calculate your downtime costs as the first input to that comparison. The point isn't to buy the tightest possible target across the board; it's to buy the target that's actually justified by what an outage would genuinely cost this business, for this application.

Common Pitfalls in RTO/RPO Planning

Several recurring mistakes undermine otherwise sensible recovery plans, and most of them come from treating RTO and RPO as IT settings rather than business commitments.

• •Conflating the two metrics: assuming a fast RTO automatically means a tight RPO, when they answer entirely different resilience questions and a plan strong on one can still be weak on the other.
• •Writing a target the infrastructure can't actually meet: a "15-minute RPO" in a policy document is meaningless if the capture interval running in production is longer than that.
• •Forgetting that RPO is realised, not designed, at the moment of failure — as the 24-hour example shows, the RPO you get is the age of the last backup that actually exists, whatever the policy says it should be.
• •Never testing whether the stated RTO is achievable under real conditions, rather than in a controlled, best-case scenario.

Continuous Improvement: Treat These as Living Targets

Because RTO and RPO are business-set tolerances rather than fixed technical facts, they should move as the business changes — new customer-facing services, new regulatory exposure, and new dependency chains all shift what "acceptable" looks like for a given process.

Testing is what turns a stated target into a genuine capability rather than an assumption. Regularly rehearsing recovery is the only way to know whether the interval defined on paper matches what actually happens when a system goes down — before you find out during a real outage, it's worth taking the time to understand if your RTO is realistic.

Sources

Every figure in this article traces to the sources below.

• •Veeam — RTO and RPO definitions and paired example targets
• •TechTarget — RTO/RPO measurement direction and units
• •Rubrik — 24-hour RPO worked example
• •AWS — RTO/RPO framing for cloud applications
• •Druva — why RTO and RPO shouldn't be conflated
• •Commvault — the cost trade-off of tighter recovery targets
• •Ncontracts — RTO/RPO as business continuity metrics
• •Eon — RPO as data-age framing