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

> RPO is how much data you can lose; RTO is how long recovery takes. How to set both per system, design for them, test them and write the disaster recovery plan.

- URL: https://computese.com/rto-vs-rpo/
- Author: Duong Quan Nguyen, CEO, Computese
- Published: 2026-10-30
- Updated: 2026-10-30
- Topics: Cloud, Hosting

## In short
- RPO is how much data you can afford to lose, as time back from the failure. RTO is how long a system may stay down. They are separate numbers, set per system by the business, and the RTO must normally be shorter than the MTD.
- The RTO clock starts at the incident, so detection and approval time count. RPO depends mostly on backup frequency and replication mode; RTO on standby capacity, automation, DNS and the decision to fail over.
- AWS ranks four strategies by cost and complexity, from backup and restore (RPO in hours, RTO of 24 hours or less) to multi-site active/active (RPO near zero, RTO potentially zero). Choose the cheapest one that meets each system's target.
- Replication may not protect against corruption or malicious deletion as well as point-in-time backups do, so keep both, with one copy offline or immutable. After ransomware, your real RPO is the age of the last clean copy.
- A target is a guess until a drill measures it. Run a tabletop, a component restore and a full failover, record the measured RTO and RPO, then fix the gap or change the target.

RPO (recovery point objective) is the most data you can afford to lose, counted as time back from the failure. RTO (recovery time objective) is how long a system may stay down before the harm is unacceptable. RPO sets how often you must copy data. RTO sets how fast you must be able to bring service back.

For the copies themselves, see our guides to a [data backup strategy](https://computese.com/how-to-create-a-data-backup-strategy/) and a [secure backup strategy](https://computese.com/how-to-create-a-secure-backup-strategy-for-your-data/). Vendor details are as documented in October 2026.

## What do RTO, RPO and MTD mean?

[NIST SP 800-34 Rev. 1](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf) 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.

| Aspect            | RPO                                | RTO                                             |
| ----------------- | ---------------------------------- | ----------------------------------------------- |
| The question      | How much data can we lose?         | How long can we be down?                        |
| Counted as        | Last good copy to the incident     | The incident to restored service                |
| Mostly decided by | Backup frequency, replication mode | Standby capacity, automation, DNS, dependencies |

These are disaster recovery targets, and [high availability is not disaster recovery](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/high-availability-is-not-disaster-recovery.html): 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](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html), so noticing the problem and finding an approver both count.

![A timeline runs left to right: a database cylinder, a cracked server beside a lightning bolt, a clock, then a server with a check mark. An orange bracket under the line reaches back from the bolt to the cylinder.](https://computese.com/images/blog/rto-vs-rpo/last-copy-bracket.b00f06756f-1536.webp)

*The RPO looks back from the incident to the last good copy; the RTO looks forward to restored service.*

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

| Moment                 | Design A: backup every 8 hours, rebuild on demand | Design B: warm standby, asynchronous replication |
| ---------------------- | ------------------------------------------------- | ------------------------------------------------ |
| Last good copy         | 06:00                                             | 13:39:59                                         |
| Incident               | 13:40                                             | 13:40                                            |
| Detected               | 13:55                                             | 13:41                                            |
| Declared               | 14:20                                             | 13:46                                            |
| Service back           | 16:35                                             | 14:05                                            |
| Verified               | 17:05                                             | 14:15                                            |
| Data lost (actual RPO) | 7 h 40 min                                        | About 1 second                                   |
| Time down (actual RTO) | 2 h 55 min                                        | 25 min                                           |

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](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html), so an 8-hour schedule cannot meet a 15-minute RPO.

PostgreSQL shows the mechanics. Its [archive command runs only for completed WAL segments](https://www.postgresql.org/docs/18/runtime-config-wal.html), 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](https://www.postgresql.org/docs/18/continuous-archiving.html) needs `wal_level` of `replica` or higher, `archive_mode` on and an `archive_command` or `archive_library`:

```ini
# 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](https://www.postgresql.org/docs/18/warm-standby.html) 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.

![A laptop writes to a database cylinder. A copy travels across a dashed line to a second cylinder, and an orange arrow with a check mark returns while an hourglass sits on the first cylinder.](https://computese.com/images/blog/rto-vs-rpo/commit-waits.99ad7c5d11-1536.webp)

*A synchronous commit waits for the standby, so each commit pays at least the round trip between primary and standby.*

> [!WARNING]
> If a synchronous standby crashes, commits on the primary may never complete. PostgreSQL's advice is to name several candidates in `synchronous_standby_names`, for example `'ANY 1 (standby_a, standby_b)'`.

To watch the delay, query the [`pg_stat_replication` view](https://www.postgresql.org/docs/18/monitoring-stats.html), which reports `write_lag`, `flush_lag` and `replay_lag` per standby:

```sql
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](https://computese.com/work/banking-platform-migration/), 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](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html), 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](https://www.postgresql.org/docs/18/warm-standby-failover.html) 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](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html), 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](https://computese.com/infrastructure-as-code/)), and check the recovery site's capacity, [service quotas and throttle limits](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html).

**The recovery path.** For maximum resiliency, AWS advises using [only data plane operations](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html) 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](https://www.rfc-editor.org/rfc/rfc1035.html) 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](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-basic.html). 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](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-determining-health-of-endpoints.html). 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](https://computese.com/website-migration-seo/) does for cutovers.

![Three laptops reach a resolver box with an orange clock face, which still sends them to a cracked upper server. A new record pointing at the lower server floats above, its dashed line stopping short of the resolver.](https://computese.com/images/blog/rto-vs-rpo/ttl-cache.ac30940b01-1536.webp)

*Until its cached copy expires, a resolver keeps sending clients to the old address.*

## Which recovery strategy fits which targets?

AWS describes [four approaches](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html) and [lists them in increasing order of cost and complexity, and decreasing order of RTO and RPO](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html):

| Strategy                 | RPO                                                            | RTO              | What waits in the recovery site                              |
| ------------------------ | -------------------------------------------------------------- | ---------------- | ------------------------------------------------------------ |
| Backup and restore       | In hours (5 minutes in some cases with point-in-time recovery) | 24 hours or less | Backups only                                                 |
| Pilot light              | In minutes                                                     | Tens of minutes  | Replicated data and core resources; app servers switched off |
| Warm standby             | In seconds                                                     | Minutes          | A scaled-down, fully working copy                            |
| Multi-site active/active | Near zero                                                      | Potentially zero | The full workload, serving traffic                           |

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.

![Two sites side by side. The left site has a database and three solid servers. The right site has the same layout with dashed, waiting servers. A stream of documents flows between the two databases along an orange arrow.](https://computese.com/images/blog/rto-vs-rpo/standby-waits.30d4ba7b82-1536.webp)

*In both standby strategies the data is already at the second site; what differs is how much compute is running.*

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](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html), 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](https://learn.microsoft.com/en-us/azure/site-recovery/site-recovery-faq) 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)](https://www.ibm.com/think/topics/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](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf). 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](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html).

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

| Tier        | Example systems                      | RTO         | RPO        | A design that fits                             |
| ----------- | ------------------------------------ | ----------- | ---------- | ---------------------------------------------- |
| 1, critical | Checkout, payments, customer sign-in | Minutes     | Seconds    | Warm standby with replication                  |
| 2, high     | Order management, ERP                | 4 hours     | 15 minutes | Pilot light or standby database, log archiving |
| 3, medium   | Reporting, brochure website          | 24 hours    | 24 hours   | Daily backup, rebuild from code                |
| 4, low      | Test and development                 | Best effort | None       | No recovery site                               |

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](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf). For less critical workloads, [a valid strategy may be not to have any disaster recovery in place at all](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html), 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](https://computese.com/the-importance-of-backup-solutions-for-website/) 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](https://learn.microsoft.com/en-us/azure/site-recovery/site-recovery-overview).

![Five square tiles joined by arrows: a key, a padlock, a database, a server and a globe. The key tile is orange and sits alone inside a dashed, cracked frame; the other four tiles have dashed outlines and wait.](https://computese.com/images/blog/rto-vs-rpo/chain-first-link.97afea75cc-1536.webp)

*A restore runs as a chain, and it stalls at the first link that is missing.*

| Dependency              | How it stalls recovery                                       | What to do                                                                               |
| ----------------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------- |
| Identity                | Nobody can sign in to start the restore                      | Keep tested emergency admin accounts that do not depend on the failed directory          |
| DNS and certificates    | Clients keep the old address; the standby has no certificate | Lower the TTL; build certificates and renewal into the recovery site                     |
| Secrets and keys        | Restored data cannot be decrypted                            | Keep key copies apart from the backups; test a restore from the recovery site            |
| Licences and installers | Some images will not install on different hardware           | Keep source code or executables with the offline backups, plus licence agreements (CISA) |
| People                  | The one person who knows the steps is away                   | A named authority and successor, checklists, an offline plan                             |

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](https://computese.com/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](https://www.cisa.gov/stopransomware/ransomware-guide) 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.

![Plain documents stand on a shelf, oldest on the left, followed by three hatched ones that carry padlocks. A mechanical arm lifts the newest plain document, drawn in orange, toward a server tower.](https://computese.com/images/blog/rto-vs-rpo/clean-copy.b27b7f4459-1536.webp)

*After ransomware, the copy to restore is the newest clean one, not simply the newest one.*

- **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](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) 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](https://computese.com/how-to-create-a-secure-backup-strategy-for-your-data/) 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](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html) 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:

| Exercise (NIST)                                | What you do                                                                  | What it proves                                             |
| ---------------------------------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------- |
| Tabletop, for low-impact systems               | Talk through a scenario; nothing is deployed                                 | Roles, activation criteria and contacts                    |
| Functional, for moderate-impact systems        | Restore one database or server from backup into a scratch environment, timed | The achieved RPO (age of the data) and a real restore time |
| Full-scale functional, for high-impact systems | Fail over to the recovery site, run there, then recover and reconstitute     | The end-to-end RTO, the dependency chain and failback      |

> [!TIP]
> Start the stopwatch when you inject the failure, not at the first command, so that detection and approval time show up in the result.

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

```yaml
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](https://computese.com/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](https://computese.com/work/financial-dr-automation/), 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](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html). 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:

| Section                        | What it holds                                                                            | Owner                            |
| ------------------------------ | ---------------------------------------------------------------------------------------- | -------------------------------- |
| 1. Scope and targets           | Systems, tiers, MTD, RTO and RPO, a link to the BIA                                      | Business owner of each system    |
| 2. Roles and contacts          | One named person with authority to declare a disaster, a named successor, teams, vendors | DR coordinator                   |
| 3. Activation and notification | Criteria, who to notify and how, how to assess the outage                                | The person with authority        |
| 4. Recovery procedures         | Per system, in priority order: steps, commands, expected results, time checks            | Engineering owner of each system |
| 5. Reconstitution              | Validating data and function, failback, clean-up                                         | Engineering and business owners  |
| 6. Appendices and upkeep       | BIA, dependency list, diagrams, licences, an offline copy, exercise and review dates     | DR coordinator                   |

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](https://www.cisa.gov/stopransomware/ransomware-guide) for incident response plans.

### Which mistakes make a plan fail?

| Mistake                                   | What happens                                     | Instead                                             |
| ----------------------------------------- | ------------------------------------------------ | --------------------------------------------------- |
| Starting the RTO clock at the declaration | Real downtime is longer than reported            | Start at the incident                               |
| Treating replication as a backup          | A delete or encryption can reach the standby too | Keep point-in-time copies, one offline or immutable |
| Never testing                             | The first test is the real incident              | Time a tabletop, a restore and a failover           |
| A recovery site that drifts               | The failover can fail on the day                 | Build both sites from code and check quotas         |

## 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](https://computese.com/services/hosting-maintenance/) service writes RPO and RTO down per site and proves them with restore drills, and our [cloud transformation](https://computese.com/services/cloud-transformation/) work includes backup and disaster recovery drills. If your disaster recovery exists only on paper, start with a timed restore.

## Key terms
- **Recovery point objective (RPO)**: The most data loss a business accepts, expressed as time. NIST describes it as the point in time, before an outage, to which data can be recovered, given the most recent backup copy.
- **Recovery time objective (RTO)**: The longest a system may stay unavailable before the impact becomes unacceptable. AWS defines it as the maximum acceptable delay between the interruption of service and restoration of service.
- **Maximum tolerable downtime (MTD)**: In NIST SP 800-34, the total time the system owner will accept for an outage of a business process, counting all impact considerations. The RTO must normally be shorter than the MTD.
- **Business impact analysis (BIA)**: A study of what an outage does to each business process and system. NIST's BIA determines processes and recovery criticality, resource requirements and recovery priorities; AWS says it should help determine how quickly a workload must be available and how much data loss can be tolerated.
- **Pilot light**: An AWS recovery strategy in which data is replicated to the recovery site and core resources such as databases are always on, but application servers are switched off, so it cannot process requests without further action.
- **Warm standby**: An AWS recovery strategy that keeps a scaled-down but fully functional copy of the workload always running in the recovery site, so it can handle traffic at reduced capacity immediately and then scale up.
- **Point-in-time recovery (PITR)**: Restoring a database to its state at a chosen moment, not just the last backup. In PostgreSQL you restore a base backup and replay archived WAL, stopping at a recovery target such as a date and time.
- **Asynchronous and synchronous replication**: Asynchronous replication confirms a commit before the standby has it, so a failover can lose the replication delay. Synchronous replication makes the commit wait for the standby's disk, so data is lost only if both servers crash, at the cost of latency.
- **Disaster recovery as a service (DRaaS)**: A third-party service that delivers data protection and disaster recovery on demand and pay as you go, replicating and hosting servers for failover. IBM says that in a DRaaS model the service-level agreements cover the RTO.
- **Tabletop exercise**: A discussion-based test of a plan in which the team talks through a scenario and no equipment or other resources are deployed. NIST says it is sufficient for low-impact systems.

## Common questions

### What is the difference between RTO and RPO?

RPO is how much data you can lose, measured as the time between the last good copy and the incident. RTO is how long the service can be down, measured from the incident to restored service. You meet an RPO by copying data often enough, and an RTO by being able to bring the service back fast enough. Each is set per system from the business impact.

### Which is more important, RTO or RPO?

Neither in general. They answer different questions, and the business sets each one from what downtime and data loss cost. A system that holds the only record of orders needs a tight RPO, while one that can rebuild its data from other sources may need only a fast RTO.

### Can RTO or RPO be zero?

Close to it, at a high cost. AWS rates multi-site active/active at an RPO near zero and an RTO potentially zero, lists it last in order of cost and complexity and calls it the most operationally complex strategy. AWS also lists, among its anti-patterns, unrealistic recovery objectives such as zero time to recover or zero data loss, which may not be achievable for your workload configuration. Synchronous replication in PostgreSQL loses a committed transaction only if the primary and the standby both crash at once, but replication may not protect against corruption or malicious deletion as well as point-in-time backups do.

### What is maximum tolerable downtime, and how does it relate to RTO?

NIST defines the maximum tolerable downtime (MTD) as the total time the system owner will accept for an outage of a business process, counting all impact considerations. The RTO is the longest a system resource can be unavailable before it threatens that limit, so the RTO must normally be shorter than the MTD.

### What is the difference between backup and disaster recovery?

A backup is a copy of data. Disaster recovery brings a whole service back after a large event, often at another site, and is measured by the RTO and RPO. AWS puts backup and restore at the low-cost, low-complexity end of its four strategies, with an RTO of 24 hours or less, and says how often you run your backup determines your achievable recovery point.

### What is disaster recovery as a service (DRaaS)?

IBM describes DRaaS as a third-party solution that delivers data protection and disaster recovery capabilities on demand, over the internet, on a pay-as-you-go basis. The provider replicates and hosts your servers for failover, and IBM says the SLA covers the RTO. IBM also says backup as a service costs significantly less than DRaaS.

### How often should you test a disaster recovery plan?

At least once a year, and after significant changes. NIST's sample policy says recovery capabilities and personnel shall be tested annually, and NIST says testing should also happen when significant changes are made to the system, the business process or the plan. AWS says the only error recovery that works is the path you test frequently.

## Sources
1. [Contingency Planning Guide for Federal Information Systems (SP 800-34 Rev. 1)](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf), NIST
2. [High availability is not disaster recovery, Disaster Recovery of Workloads on AWS](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/high-availability-is-not-disaster-recovery.html), Amazon Web Services
3. [Business Continuity Plan (BCP), Disaster Recovery of Workloads on AWS](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html), Amazon Web Services
4. [Disaster recovery options in the cloud, Disaster Recovery of Workloads on AWS](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html), Amazon Web Services
5. [19.5. Write Ahead Log, PostgreSQL 18](https://www.postgresql.org/docs/18/runtime-config-wal.html), PostgreSQL Documentation
6. [25.3. Continuous Archiving and Point-in-Time Recovery (PITR), PostgreSQL 18](https://www.postgresql.org/docs/18/continuous-archiving.html), PostgreSQL Documentation
7. [26.2. Log-Shipping Standby Servers, PostgreSQL 18](https://www.postgresql.org/docs/18/warm-standby.html), PostgreSQL Documentation
8. [27.2. The Cumulative Statistics System, PostgreSQL 18](https://www.postgresql.org/docs/18/monitoring-stats.html), PostgreSQL Documentation
9. [26.3. Failover, PostgreSQL 18](https://www.postgresql.org/docs/18/warm-standby-failover.html), PostgreSQL Documentation
10. [REL13-BP04 Manage configuration drift at the DR site or Region](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html), AWS Well-Architected Framework
11. [RFC 1035: Domain Names, Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035.html), IETF
12. [Values specific for simple records, Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-basic.html), Amazon Web Services
13. [How Amazon Route 53 determines whether a health check is healthy](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-determining-health-of-endpoints.html), Amazon Web Services
14. [REL13-BP02 Use defined recovery strategies to meet the recovery objectives](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html), AWS Well-Architected Framework
15. [General questions about the Azure Site Recovery service](https://learn.microsoft.com/en-us/azure/site-recovery/site-recovery-faq), Microsoft Learn
16. [What Is Disaster Recovery as a Service (DRaaS)?](https://www.ibm.com/think/topics/draas), IBM
17. [REL13-BP01 Define recovery objectives for downtime and data loss](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html), AWS Well-Architected Framework
18. [About Azure Site Recovery](https://learn.microsoft.com/en-us/azure/site-recovery/site-recovery-overview), Microsoft Learn
19. [#StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide), CISA
20. [Locking objects with Object Lock, Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html), Amazon Web Services
21. [REL13-BP03 Test disaster recovery implementation to validate the implementation](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html), AWS Well-Architected Framework