RPO vs RTO: Setting Disaster Recovery Targets

RPO (Recovery Point Objective) and RTO (Recovery Time Objective) are the two numbers that define a disaster recovery plan: RPO is how much data you can afford to lose, measured backward in time from the failure; RTO is how long you can afford to be down before service is restored. Every backup schedule, replication strategy, and failover design is ultimately an answer to these two questions.

The two questions, separated

It’s easy to conflate “how fast can we recover” with “how much do we lose,” but they measure different things and are driven by different engineering decisions.

RPO answers: if the primary system fails right now, how far back does our most recent usable backup or replica go? An RPO of 15 minutes means you’re willing to lose up to 15 minutes of writes — anything committed after the last successful backup or replication checkpoint is gone. RPO is fundamentally about backup and replication frequency.

RTO answers: once we know we need to recover, how long until the system is serving traffic again? An RTO of one hour means the outage window — from failure to restored service — must not exceed an hour. RTO is about the mechanics of failover: provisioning replacement infrastructure, restoring data, redirecting traffic, and validating the result.

A system can have an aggressive RPO and a lax RTO, or the reverse. A financial ledger might tolerate almost no data loss (RPO near zero, achieved with synchronous replication) but accept a multi-hour recovery window if the failure mode is rare enough. A read-heavy content site might tolerate losing the last hour of analytics events (a loose RPO) but need to be back online within minutes because every minute down is lost traffic.

What drives each number

RPO is set by your replication and backup strategy:

• Continuous/synchronous replication to a standby — RPO approaches zero, but at a latency and infrastructure cost, since every write must be acknowledged by the replica before the transaction commits.
• Asynchronous replication — RPO is the replication lag, typically seconds to low minutes.
• Periodic backups (hourly, nightly) — RPO equals the backup interval, since anything written between backups is at risk.

RTO is set by how automated your failover is:

• Manual recovery from cold backups — RTO can be hours: someone has to notice the failure, provision new infrastructure, restore data, and repoint traffic.
• Warm standby, kept running but not serving traffic — RTO drops to minutes, since the standby just needs to be promoted and traffic redirected.
• Active-active deployment across regions — RTO can approach zero, since failure detection and traffic rerouting happen automatically. See active-active vs active-passive architecture for how that tradeoff is usually made.

Notice that RPO and RTO aren’t purchased independently — a warm standby that shortens RTO usually needs to be kept reasonably in sync with the primary to be useful at all, which pulls its replication lag, and therefore RPO, down as a side effect. Designing for one in isolation tends to leave the other worse than it needs to be for the same infrastructure spend.

RPO vs RTO at a glance

	RPO	RTO
Measures	Acceptable data loss	Acceptable downtime
Driven by	Backup/replication frequency	Failover automation
Tightened by	More frequent snapshots, sync replication	Standby infrastructure, automated failover
Cost driver	Storage and replication bandwidth	Idle standby capacity, orchestration tooling
Typical unit	Minutes to hours	Minutes to hours

Setting realistic targets

The temptation is to set both to zero. In practice, every reduction in RPO or RTO costs money: synchronous replication across regions adds write latency and infrastructure; hot standbys mean paying for capacity that sits idle until a failure occurs. The right targets come from asking what an hour, or a day, of data loss or downtime actually costs the business — in revenue, in regulatory exposure, in customer trust — and pricing the recovery infrastructure against that.

This is also where SLOs and SLAs intersect with disaster recovery: an external SLA promising 99.95% uptime constrains your RTO budget for the year, while data-integrity commitments to customers constrain RPO. Different tiers of a system often warrant different targets — a primary transactional database might justify synchronous replication and an automated failover, while an internal analytics warehouse might be fine with nightly backups and a half-day recovery window.

Testing the plan

An RPO and RTO on paper mean nothing until they’re exercised. A disaster recovery plan that has never been tested tends to fail in ways nobody anticipated: restore scripts that haven’t run in a year, credentials that expired, DNS TTLs set too high to fail over quickly, runbooks that reference infrastructure that no longer exists. Regular failover drills — ideally including an unannounced one occasionally — are what turn a target on a slide into a number you can actually trust during a real disaster recovery event.

The takeaway

RPO bounds how much data a failure can cost you; RTO bounds how long the failure can keep you down. They’re set independently, driven by different infrastructure choices, and each tighter target has a real cost — so the right values come from what an outage or data loss actually costs the business, not from defaulting to zero. Once targets are set, the only way to trust them is to actually fail over and measure what happens.