A backup is evidence that some state may be recoverable. A recovery objective is a claim about how much state can be lost and how quickly a usable service can return. I would connect those claims with a measured restore-and-replay budget, including the dependencies and validation steps that sit outside the database files.
Define the failure before choosing the recovery target
Recovering from one lost disk is different from recovering after regional loss, compromised credentials or an application that corrupted valid data for several hours. Replication can help with hardware failure while faithfully copying logical corruption. A backup in the same account can be available during a machine failure and inaccessible during an identity or policy failure. I would state the scenario for each recovery plan, including which people, credentials, regions and control-plane services remain available. Without that boundary, a short recovery-time claim can depend on resources the scenario explicitly removes.
AWS's disaster-recovery guidance distinguishes approaches such as backup and restore, pilot light, warm standby and active-active operation. These are useful categories for capacity and preparedness, not universal recovery guarantees. My interpretation is that every option still needs a concrete dependency graph and a rehearsed procedure. A warm application fleet cannot serve useful requests if its encryption keys, database credentials or routing controls cannot be recovered. Conversely, a well-tested restore process can be entirely appropriate when the product's time and data-loss objectives allow it.
References: [2] AWS disaster recovery options in the cloud
RPO follows durable recoverable state
Recovery point objective concerns the amount of recent state the organisation is prepared to lose. A backup job's start time or green scheduler status is not sufficient evidence. The relevant point is the newest state that can be reconstructed from verified durable artifacts in the failure domain that survives. PostgreSQL's continuous-archiving documentation describes recovery using a base backup and the required sequence of WAL. A missing required segment can break the chain even when many later files exist. Recoverability depends on completeness, not simply the timestamp of the newest object.
I would measure the lag between committed source state and the latest verified recoverable position at the destination. The measurement should include archive transfer, durability acknowledgement and any validation needed to trust the copy. If encryption keys rotate, old backup material must remain decryptable for its retention period under the intended recovery permissions. A nominal five-minute RPO is unsupported if archive failures can remain unnoticed for an hour. Alerting should therefore focus on the age of recoverable state and broken continuity, rather than only whether the latest scheduled task exited successfully.
References: [1] PostgreSQL continuous archiving and point-in-time recovery
Build an end-to-end time ledger
Consider an illustrative restore requiring a 2 TB base image and 300 GB of subsequent log, using decimal units throughout. If effective base restore throughput is 500 MB per second, copying the image takes 4,000 seconds. If effective replay throughput is 150 MB per second, replay takes another 2,000 seconds. Sequential execution therefore consumes 100 minutes before configuration, validation and traffic cutover. These rates are assumptions for arithmetic, not measurements or product promises. Compression, network limits, storage writes and replay CPU can each change the effective throughput.
The calculator makes the budget explicit and adds a hypothetical twenty minutes for validation and cutover. Some systems overlap stages, while others have dependencies that force them to run sequentially. I would model the actual critical path rather than adding every task or assuming perfect parallelism. Include detection and decision time when the organisation's RTO starts at the incident, because a technically fast restore cannot recover time spent deciding whether to invoke it. The useful estimate has enough detail that a rehearsal can replace assumptions with observed values.
base_bytes = 2 * 10**12
log_bytes = 300 * 10**9
restore_rate = 500 * 10**6
replay_rate = 150 * 10**6
validation_seconds = 20 * 60
restore = base_bytes / restore_rate
replay = log_bytes / replay_rate
total = restore + replay + validation_seconds
assert restore == 4000
assert replay == 2000
assert total / 60 == 120
print({'restore_minutes': restore / 60,
'replay_minutes': replay / 60,
'total_minutes': total / 60})References: [1] PostgreSQL continuous archiving and point-in-time recovery[2] AWS disaster recovery options in the cloud
A moving target needs spare replay capacity
If recovery catches up with a source that is still accepting writes, replay must outrun new log generation. Let the backlog be B bytes, incoming log rate be lambda and replay service rate be mu. Under a steady simplified model with mu greater than lambda, catch-up time is B divided by mu minus lambda. With a 300 GB backlog, 150 MB per second replay and 50 MB per second incoming log, the estimate is 3,000 seconds, or fifty minutes. Using backlog divided by replay rate alone would underestimate the moving-target recovery time.
If mu is no greater than lambda, the backlog never drains under those assumptions. More time is not a solution; the plan needs faster replay, reduced incoming work or a cutover strategy that temporarily bounds new writes. Real workloads vary, so the model should be checked with representative log and hardware rather than treated as a deterministic forecast. I would pay attention to the slow tail of replay, including large transactions and data structures that behave differently on a cold system. The rate that matters is useful progress through the required history, not peak network throughput.
References: [1] PostgreSQL continuous archiving and point-in-time recovery
Recover the service's meaning, not only its files
PostgreSQL notes that WAL recovery does not restore every configuration file change. More broadly, a usable service may depend on application artifacts, schema versions, secrets, identity configuration, object storage and external integrations. I would keep a versioned recovery manifest describing which components belong together and how each is obtained in the assumed failure scenario. The manifest itself must be reachable without the failed system. A database restored successfully but paired with an incompatible application release can turn a storage recovery into a new correctness incident.
Point-in-time recovery also creates a relationship with external effects that were already observed. Restoring the database to before a payment or email was recorded does not undo the external action. Replaying blindly can repeat it. A recovery procedure needs a policy for reconciling outbound operations, disabling unsafe side effects during verification and identifying the recovered authority before live traffic resumes. This is why I would rehearse with controlled integrations or delivery sinks. A test restore should prove recovery without accidentally sending real notifications or creating new effects in production services.
References: [1] PostgreSQL continuous archiving and point-in-time recovery
Choose the preparation that the objective justifies
A counterargument is that maintaining warm standby capacity is expensive when serious failures are rare. That is true, and the right response is a quantified comparison. If backup restore cannot meet the agreed RTO even under optimistic throughput assumptions, the gap must be closed through more preparation, a smaller recoverable dataset, faster infrastructure or a revised objective. Calling a slow strategy highly available does not change the arithmetic. Equally, an active-active system may introduce coordination and operational risks that are unjustified for a service whose users can tolerate a longer recovery.
Retention and isolation should follow the threat model as well. Several recent copies can help with accidental deletion but may all contain a corruption that went undetected for weeks. Immutable or separately controlled copies can protect against some destructive actions, but they require tested access and key recovery. I would not present any one storage feature as complete protection against every failure. The recovery design is a portfolio of time points, failure domains and procedures, chosen so that the relevant scenario leaves at least one usable path back to a known state.
References: [2] AWS disaster recovery options in the cloud
Make rehearsals produce evidence
A recovery rehearsal should record the selected recovery point, artifacts used, integrity checks, elapsed time for each critical stage and the application validation performed. Querying a restored database is necessary but not sufficient; exercise representative reads, writes and invariants with external effects controlled. Include a missing segment, unavailable credential or incompatible application artifact in some rehearsals so the procedure demonstrates how it detects and explains failure. A runbook that works only when every dependency is already prepared has not tested the most important assumptions.
The result should update the recovery budget rather than merely produce a pass badge. If replay dominates, investigate history volume and replay capacity. If human coordination dominates, simplify authority and decision procedures. If validation dominates, automate checks whose meaning is stable while preserving human review for ambiguous business outcomes. Disaster recovery becomes credible when the team can point to a recoverable position and a demonstrated path to service within the chosen objective. The backup is one input; the replay budget and the evidence around it establish the actual promise.
References: [1] PostgreSQL continuous archiving and point-in-time recovery[2] AWS disaster recovery options in the cloud
Sources and further reading
- PostgreSQL continuous archiving and point-in-time recovery
Primary documentation defines base-backup and WAL recovery requirements and configuration limits. Recovery rates, capacities and incident scenarios in the essay are explicitly hypothetical.
- AWS disaster recovery options in the cloud
Primary architecture guidance distinguishes recovery strategies. The time ledger and tradeoff analysis are the essay's own reasoning, not vendor RTO guarantees.