RTO vs RPO: set recovery targets and build a disaster recovery plan

What do RTO, RPO and MTD mean?

NIST SP 800-34 Rev. 1 defines three terms. The maximum tolerable downtime (MTD) is the total time the system owner will accept for an outage of a business process, including all impact considerations. The RTO is the longest a system resource can stay unavailable before the impact on other resources, the processes they support and the MTD becomes unacceptable. The RPO is the point in time, before the outage, to which data can be recovered, given the most recent backup copy.

The RTO must normally be shorter than the MTD, and time spent reprocessing data after recovery must be added to it. The RPO is not part of the MTD: it reflects how much data loss the process can tolerate, so a system can have a tight RPO and a loose RTO, or the reverse.

These are disaster recovery targets, and high availability is not disaster recovery: availability focuses on components of the workload, whereas disaster recovery focuses on discrete copies of the entire workload, says AWS.

What does a recovery timeline look like?

An outage moves through the same moments: last good copy, incident, detection, decision, restore and verification. The RPO is the gap from the last good copy to the incident. The RTO runs from the incident to restored service, not from the decision: AWS defines it as the maximum acceptable delay between the interruption of service and restoration of service, so noticing the problem and finding an approver both count.

The table runs one invented outage through two designs. The times are examples, not benchmarks.

In both designs about a quarter of the downtime passes before anyone starts recovering: 40 of 175 minutes in A, 6 of 25 in B. A faster restore does not shorten that part; monitoring, written activation criteria and a named decision-maker do. Decide where the clock stops, too: if users wait for NIST's reconstitution checks (recovered data first, then function), count them.

What does your RPO decide?

The RPO fixes how often a recoverable copy has to exist. AWS says how often you run your backup determines your achievable recovery point, so an 8-hour schedule cannot meet a 15-minute RPO.

PostgreSQL shows the mechanics. Its archive command runs only for completed WAL segments, so a quiet server can leave a long delay before the latest commits are safely archived. archive_timeout forces a switch to a new segment periodically; the documentation calls a minute or so usually reasonable and warns that a very short value bloats archive storage. Continuous archiving needs wal_level of replica or higher, archive_mode on and an archive_command or archive_library:

# postgresql.conf on the primary, PostgreSQL 18
wal_level = replica     # the default
archive_mode = on       # changing it needs a restart
archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
archive_timeout = 60    # seconds

That archive_command is the documentation's example, not a recommendation. If archiving falls significantly behind, the data lost in a disaster increases. For anything tighter than a minute or so, the documentation says to consider streaming replication.

Streaming replication keeps a standby server up to date by sending WAL as it is generated. It is asynchronous by default, with a delay typically under one second if the standby keeps up, and the data lost in a failover is proportional to the replication delay at that moment. Synchronous replication closes the gap: a commit waits until the WAL is on disk on both servers, so data is lost only if both crash at once. The minimum wait is the round-trip time between them.

To watch the delay, query the pg_stat_replication view, which reports write_lag, flush_lag and replay_lag per standby:

SELECT application_name, sync_state, write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

Teams that accept asynchronous replication plan for the gap. A bank's move from OpenShift 3 to 4, one of our case studies, worked to "recovery in minutes, data loss in seconds": asynchronous replication over a high-bandwidth, low-latency link, plus runbooks for data not yet replicated.

Replication also copies mistakes. AWS warns that continuous replication may not protect against data corruption or malicious attack, such as unauthorized data deletion, as well as point-in-time backups do. Keep both: replication for the last seconds, archived copies for the moment before the mistake.

What does your RTO decide?

The RTO covers everything between the incident and a working service, and restoring data is only part of it.

Detection and the decision. PostgreSQL does not provide the system software required to identify a failure on the primary and notify the standby, so a separate tool or a person does, then promotes the standby with pg_ctl promote or pg_promote(). AWS says automatically initiated failover should be used with caution, because failing over on a false alarm incurs some loss of availability and data. Manual initiation is therefore often used, with the steps automated so that it is like the push of a button.

Automation. Rebuilding servers by hand spends the RTO: without infrastructure as code, AWS says, restoring workloads may be complex and possibly exceed your RTO. Define both sites in code (see our guide to infrastructure as code), and check the recovery site's capacity, service quotas and throttle limits.

The recovery path. For maximum resiliency, AWS advises using only data plane operations in a failover, because data planes typically have higher availability design goals than control planes. Restoring from backup is a control plane operation, so AWS says a scheduled periodic restore is a good idea.

DNS. Clients keep the old address until their cached record expires. RFC 1035 defines the TTL as the time, in seconds, that a record may be cached, and Route 53 notes that a longer TTL makes changes take longer. Health checks add detection time: Route 53 lets you choose an interval of 10 or 30 seconds between checks, and a failure threshold of consecutive checks. As an illustration, three failed 30-second checks and a 60-second TTL add up to about two and a half minutes before most clients reach the new address. Lower the TTL ahead of planned moves, as our website migration guide does for cutovers.

Which recovery strategy fits which targets?

AWS describes four approaches and lists them in increasing order of cost and complexity, and decreasing order of RTO and RPO:

The two middle rows differ in compute. A pilot light cannot process requests without additional action: recovery means turning on servers, maybe deploying non-core pieces, and scaling up. A warm standby can handle traffic at reduced capacity immediately, so recovery only means scaling up. AWS suggests considering capacity reservations for EC2 instances to make sure the capacity exists.

Active/active is the most operationally complex strategy, and AWS says to select it only when business requirements necessitate it. A design across several availability zones in one Region can mitigate disaster events like fires, floods and major power outages, so a second Region is for the unlikely event that stops a workload running in a whole Region.

Managed tools have built-in numbers too. Azure Site Recovery creates a crash-consistent recovery point for Azure virtual machines every 5 minutes, which you cannot change, and its failover is not automatic: you start it with a click or a PowerShell call, so someone's decision sits inside the RTO.

Disaster recovery as a service (DRaaS) hands replication and failover to a provider. IBM describes a third-party, pay-as-you-go solution that replicates and hosts servers for failover, with an SLA that covers the RTO. It puts backup as a service typically in hours and days and DRaaS in minutes, sometimes seconds, and says the first costs significantly less.

How do you set a target for each system?

Set targets from the impact of an outage, not from what your tools can do. NIST's business impact analysis (BIA) typically has three steps: determine mission/business processes and recovery criticality, identify resource requirements, and identify system resource recovery priorities. For each workload, AWS asks, among other questions, how long it can be unavailable, how much data can be lost, whether lost data can be recreated from other sources, and whether there are legal or contractual ramifications.

AWS suggests a matrix of tiers such as critical, high, medium and low. This one is illustrative; yours comes from your analysis.

Not everything is tier 1, because each step down in RTO and RPO costs more: NIST says the shorter the RTO, the more the recovery solutions cost to implement. For less critical workloads, a valid strategy may be not to have any disaster recovery in place at all, and AWS says a strategy that costs more than the failure it prevents should not be put in place unless there is a secondary driver such as regulatory requirements.

A system also cannot recover faster than what it depends on: AWS says a workload's objectives must be achievable given the recovery capabilities of its downstream dependencies. Costs follow the tier: standby compute, replication and storage for extra copies. For a website, see our guides to website backups and website maintenance.

What else has to work before a restore can start?

A restore is a chain, and it stalls at the first missing link. Before configuring replication, Microsoft says to assess application dependencies, recovery requirements, target environment capacity and failover requirements, and to plan network connectivity.

One lesson from the bank migration was configuration: settings hard-coded per environment become manual steps during a real DR switch. Changing platform is another trigger: vSphere backup jobs rely on APIs that a new platform may not offer, a risk our VMware alternatives guide calls the backup blind spot.

How does ransomware change your RPO?

Ransomware breaks the assumption that the newest copy is the one to restore. CISA warns that many ransomware variants try to find and then delete or encrypt accessible backups. The RPO that matters is the age of the last clean copy, which can be older than the last copy. CISA also says to identify dropper malware before rebuilding from backups, to prevent continuing compromises.

• Keep an offline or immutable copy. CISA says to maintain offline, encrypted backups of critical data and test them in a disaster recovery scenario. In S3 Object Lock compliance mode, a protected object version cannot be overwritten or deleted by any user, including the root user. CISA cautions that immutable storage does not meet the compliance criteria of certain regulations and that misconfiguration can impose significant cost.
• Keep enough generations. Retention must reach back past the start of the intrusion.
• Keep what a rebuild needs. CISA recommends golden images of critical systems, source code or executables stored with the offline backups, and retained backup hardware.
• Restore in priority order. CISA says to prioritize restoration from a predefined critical asset list. Your tier table is a start on that list.

Our secure backup strategy guide covers immutable and offline copies, separate keys and clean restore tests.

How do you test RTO and RPO?

A target nobody has measured is a guess. AWS says to regularly test failover to the recovery site to verify that the RTO and RPO are met, and its experience is that the only error recovery that works is the path you test frequently. NIST matches the exercise to the system's impact level, and each rung proves something different:

Run the drill from the runbook, and record the result against the target. Example figures:

drill: orders database, primary region unavailable
targets: { rto: 30m, rpo: 1m }
measured: { detected: 2m, declared: 9m, service_back: 41m, data_age: 38s }
gap: "RTO missed by 11 minutes"
cause: "DNS TTL was 3600 seconds, not the planned 60"
fix: { owner: platform, due: 2026-11-26 }

Close the gap or change the target, and tell the business which, because the target is theirs.

Then repeat, because recovery sites drift. AWS's example: the capacity of a secondary data store, which might have been sufficient when you last tested, might no longer tolerate the load. NIST's sample policy calls for recovery capabilities and personnel to be tested annually, and a migration is a drill too: our cloud migration strategy guide has the pilot wave rehearse its rollback.

Manual drills carry their own risk. In one financial firm's checklist-and-spreadsheet drill, results depended on who was on shift, and warning signs spread across monitoring tools made declaring a disaster slow. We automated it, with a named person approving every step.

What goes into a disaster recovery plan?

AWS says a disaster recovery plan should be a subset of your business continuity plan, not a standalone document. NIST's contingency plan has five main components (supporting information, activation and notification, recovery, reconstitution and appendices) and wants plans that are clear, concise and easy to implement in an emergency, using checklists and step-by-step procedures where possible. This outline follows it:

Three details from NIST are worth copying. Activation criteria can include an expected outage longer than the RTO. Only one individual should have the authority to activate the plan, and a successor should be named. And the people assessing an outage should be able to run the procedures if the plan is inaccessible, so keep a hard copy and an offline version, as CISA advises for incident response plans.

Which mistakes make a plan fail?

Set your first recovery targets this month

1. List your systems and name a business owner for each.
2. Ask the impact questions above, assign a tier and have the owner sign it.
3. Measure today's reality. Restore one tier 1 system's data into a scratch environment and note how long the restore took and how old the data was. Those are your first measured numbers.
4. Pick the cheapest strategy that meets each tier, and record the gap and what closing it costs.
5. Write the one-page tier 1 runbook with a named authority and successor, and print a copy.
6. Book the tests: a tabletop this month and a full failover for tier 1 this year.

Computese's hosting and maintenance service writes RPO and RTO down per site and proves them with restore drills, and our cloud transformation work includes backup and disaster recovery drills. If your disaster recovery exists only on paper, start with a timed restore.