Backups preserve earlier data. Replication keeps another copy moving toward the current state. Disaster recovery as a service (DRaaS) supplies tools or managed operations for recovering workloads. A service can combine all of them. What matters is whether the copies, access and recovery procedure survive the failure you are planning for.
Start with one application and name the event: a failed database host, an accidental deletion, a lost region or a compromised production account. Each needs a different recovery path.
Match the recovery path to the failure
Use this table to review your design. These are conditions to verify, not product guarantees.
| Failure | Recovery path | What must survive |
|---|---|---|
| Database host fails | Promote a suitable standby, or restore a backup | Usable data, a working application path and control over the old writer |
| Application deletes valid records | Restore an earlier point into isolation, then repair or replace the damaged data | A retained clean point and enough evidence to identify it |
| Region becomes unavailable | Recover the application outside that region | Data copies, compute capacity and every dependency needed to serve users |
| Production credentials are stolen | Recover through a separately protected administrative path | Backup versions, recovery credentials and usable decryption keys |
Location and access are separate questions. A second region addresses a different failure boundary from a second account. Review both. AWS distinguishes multi-zone availability from recovery across regions; a standby in another zone still sits inside the same region.
Backups need a recoverable history
A backup strategy can use periodic copies, continuous log archiving or both. The useful question is which earlier states you can still reconstruct. A successful backup job tells you less than a successful restore of the state you need.
PostgreSQL's point-in-time recovery is a concrete example. You restore a base backup and replay write-ahead log (WAL) records to a chosen target. That requires an unbroken sequence of the necessary WAL files. A missing segment can prevent recovery to the target even when newer files exist. WAL recovery also does not recover edits to PostgreSQL configuration files; back those up separately. See the PostgreSQL 18 recovery documentation.
For an accidental deletion, restore into an isolated environment first. Confirm that the missing records exist there and check their relationships to other data. Then decide whether to repair selected records or replace a larger dataset. A full rollback also discards valid work after the chosen point. Plan how to identify and reconcile that work before changing production.
Retention has to cover the delay before someone notices damage. Keeping only the newest copy can leave you with a complete copy of the wrong data.
Protect access as well as the backup files
Review who can delete old versions, shorten retention or remove the keys needed to decrypt them. Include the credentials used by the backup job itself. A remote location alone does not answer those questions.
Amazon S3 Object Lock protects individual object versions. Governance mode can be bypassed with the required permission and request header. Compliance mode prevents deletion or shortening retention for a protected version through ordinary object operations, including by the account root user. New versions and delete markers can still be created, so recovery must locate the retained version. Those are specific Object Lock semantics, not evidence that a backup is clean or that an application can restore it.
A replica follows changes, including bad ones
A physical PostgreSQL standby replays the primary's WAL. A committed table deletion reaches it when the corresponding records are replayed. The replica's current state therefore cannot supply the deleted table after replay has caught up. Retained recovery history provides the earlier state.
Asynchronous replication allows the primary to acknowledge commits before the standby has them. If the primary is lost, some acknowledged work may be absent from the promoted copy. Lag varies with workload and failures; a healthy measurement taken yesterday does not establish today's recovery point.
Synchronous replication changes what a commit waits for. In PostgreSQL, durability depends on the configured synchronous standbys and the transaction's synchronous_commit setting. Waiting for a remote disk flush differs from waiting for a remote operating-system write. Required acknowledgments can also stall commits when a standby is unavailable. Check the documented acknowledgment modes before promising zero lost acknowledged transactions under a particular failure.
A network partition needs a decision about which server may write. Lost contact does not establish that the old primary is dead. Fence it so it cannot accept writes before making another server authoritative. PostgreSQL's failover guidance explains this split-brain risk and the need for external failure detection and promotion control. Include reconnecting clients and rebuilding redundancy in the procedure.
DRaaS has a boundary you must inspect
DRaaS offerings differ in what they replicate and what their operators manage. Ask for the recovery procedure for your application, including the steps your team must perform. A server that boots successfully may still lack a reachable database or working authentication.
For example, AWS Elastic Disaster Recovery replicates supported source servers into a staging area and launches recovery instances from the latest state or an earlier point. That describes server recovery. AWS separately tells customers to prepare launch subnets, security groups and instance settings.
Use a dependency list to make the boundary visible. For each database, object store, identity service and external integration, record how the recovered application reaches it. Assign an owner for DNS changes, certificates, secrets and traffic cutover. Check those steps in a drill instead of assuming they are included in a server replication service.
Ask a provider to demonstrate recovery with those dependencies present. Record where its recovery clock starts and stops, what conditions apply, and which failures the agreement covers. A quoted server launch time does not measure the time until users can complete their work.
AWS's DRS operating guidance calls for application-level drills, recording launch order and testing failback. Use those as acceptance requirements when comparing an operated service with a procedure your own team runs.
Measure the whole recovery
Set the recovery time objective (RTO), the downtime you aim to stay within, and recovery point objective (RPO), the acceptable data-loss window, for the named failure. Keep the targets separate from drill results.
Avoid assigning universal recovery times to a method. Backup recovery includes retrieving data and rebuilding the application environment. Replication still needs a safe promotion and working traffic path. AWS's recovery strategy guidance includes redeploying code, infrastructure and configuration as part of backup recovery.
For your next test, collect the following evidence:
| Record | Acceptance evidence |
|---|---|
| Recovery start and finish | Time from the agreed outage boundary until a representative user operation works |
| Recovered data boundary | An ordered record of acknowledged test writes compared with the recovered dataset |
| Recovery dependencies | Proof that access, keys and required services work without the failed component |
| Return to normal operation | A tested failback procedure and restored backup or standby protection |
Check the complete test sequence. Finding one recent row does not establish that all earlier acknowledged writes survived. Record gaps separately and explain what data your measurement covers.
Run the first restore away from production traffic. Use test credentials and block outbound payments, email and webhooks so the recovered copy cannot repeat live side effects. If you want a procedure for that exercise, use our disaster-recovery game-day guide.
External monitoring can check whether the public endpoint responds after cutover. Add an application test for the operation you are recovering, and a separate comparison for data completeness. Keep the evidence with the recovery procedure so the next operator can repeat the test and see exactly what passed.