RTO vs RPO: set recovery targets you can test

RTO sets a limit on how long a service can remain unavailable. RPO sets a limit on the data loss you will accept, expressed as time. Set both for a named business operation and failure scenario, then test whether your recovery process meets them.

A database can recover quickly with missing orders. It can also recover every order while checkout remains unavailable. You need evidence for both outcomes.

What RTO and RPO measure

Recovery time objective (RTO) is the maximum acceptable interval between service interruption and service restoration. Recovery point objective (RPO) is the maximum acceptable gap between the recovered data point and the interruption. These are targets. A drill produces measured recovery time and an observed recovery point. AWS defines the two objectives separately.

For the service-level measurement used here, start the clock when the business operation becomes unavailable. Detection, escalation and the decision to recover all consume time. Recording only the interval after someone declares an incident hides part of the outage. If a supplier measures its recovery commitment from a different trigger, record that boundary separately.

Define the finish too. For checkout, that might require a customer to sign in, place an order and retrieve its confirmation at the agreed load. A running database alone does not satisfy that definition.

The illustration below shows hypothetical targets of five minutes for RPO and twenty minutes for RTO. Its numbers explain the two directions of measurement; they are not measured results or recommended defaults.

Agree on a business operation before choosing numbers

Start with the person accountable for the operation. Describe the effect of an interruption at a busy period and at a quiet one. Separate delayed work from work permanently lost, and record which manual workarounds remain possible. AWS's business continuity guidance ties recovery choices to impact, timing, risk and cost.

Keep maximum tolerable downtime separate from the technical recovery target. NIST uses maximum tolerable downtime for the period a business process can be disrupted without significant harm. Allow room for validation and any business work that must follow the technical restore before that limit is reached.

Write down the decisions in a short recovery record:

Separate a failed database host from regional loss or a destructive data change. Each can require a different recovery path. Include dependencies whose recovery would prevent your own target from being met. AWS's recovery-objective worksheet explicitly covers dependency targets, reconstructable data and differences between incident types.

A target you cannot yet meet is an engineering gap to fund, reduce or formally accept. Keep the target and the measured capability in separate fields so a failed test cannot quietly become a weaker promise.

Work through one recovery timeline

This is a fictional exercise for checkout with a twenty-minute RTO and a five-minute RPO. Assume the recovery process can prove that all required committed data through 09:56 is present and consistent. Writes after that point are outside the recovered set. All times use the same clock.

The measured recovery time is eighteen minutes: 10:18 minus 10:00. Seven minutes passed before recovery work started. Stopping the timer when the database came up would omit three minutes of service validation.

The recovered data gap is four minutes: 10:00 minus 09:56. This exercise meets both targets under its stated assumptions. If validation instead finished at 10:23, recovery would miss the RTO by three minutes even with the same recovered data. If the latest complete point were 09:52, the eight-minute gap would miss the RPO even if checkout returned at 10:18.

A recent row timestamp cannot establish completeness. Check known committed records across the affected stores, including related objects and queued work. Otherwise, an apparently recent recovery point may conceal earlier missing data.

Backup frequency does not prove RPO

A scheduled backup only tells you when a job should run. For recovery, identify the newest usable data point that survives the failure you are planning for. A failed job, incomplete transfer or unavailable decryption key can make an older copy the only usable one.

For PostgreSQL point-in-time recovery, the documented mechanism combines a base backup with a continuous sequence of archived write-ahead log (WAL) files. The sequence must reach back to at least the start of that backup. A logical pg_dump cannot replace the base backup in that replay process. PostgreSQL also documents that WAL archiving does not restore manually edited server configuration files. Preserve those separately. See the PostgreSQL 18 recovery documentation.

A destructive change needs a usable point before the damage. Returning to an older point can discard valid changes made afterward, so record how those changes will be identified and reconciled. A replica that received the destructive change may require the same historical recovery. Our backup and replication guide covers those different recovery paths.

Choose replication settings by their guarantees

Avoid assigning a fixed RPO to labels such as active-active or warm standby. Inspect what a successful write acknowledgment means and which copy can be promoted after the specified failure.

PostgreSQL 18 streaming replication is asynchronous by default. A primary failure can lose commits that have not reached the standby. Synchronous replication can wait for selected standbys, but its durability depends on configuration: synchronous_commit=on with synchronous standbys waits for durable storage there, while remote_write waits for a write to the standby operating system without requiring a disk flush. Waiting for remote confirmation adds latency; losing the required standbys can block commits. These behaviors are described in the PostgreSQL replication documentation.

The recovery plan must also cover the application and its other stores. A database acknowledgment says nothing by itself about an uploaded file or an external payment. Define how you reconcile them before accepting new work.

Test the whole path and keep the evidence

Begin with an isolated recovery environment. Use the backups, access procedure and runbook intended for the named scenario. Prevent the test from sending customer mail, taking payments or becoming a second writer to production. Write stop conditions before introducing any failure.

Restore the data and query it. Compare known records and application relationships against the expected recovery point. Record missing data and any uncertainty instead of treating a successful restore job as proof. AWS's backup recovery testing guidance calls for checks of accessibility, integrity and data loss as well as elapsed restore time.

Then exercise the user operation at the agreed load. Keep timestamps for detection, access, restoration and validation. Record which steps were simulated or skipped. An isolated restore can demonstrate data recovery while leaving production traffic switching and full-load capacity unproven. AWS's disaster recovery testing guidance calls for exercising the recovery path and checking whether the standby still has sufficient capacity.

Attach the results to the recovery record. Give each missed target an owner and a retest condition. Revisit the record when data volume, dependencies or staffing changes enough to affect the result.

Use our disaster recovery game-day guide to turn that record into a bounded exercise with a recovery test and a stop plan.