Backup Vs Replication Recovery Design — Quick Learn
A bad deployment changes production data. The database and its standby are online, but both now contain the wrong state. This exposes the central recovery distinction:
Replication preserves a recent/current state for continuity.
Backup preserves earlier states for historical recovery.
Neither is “better.” They answer different failures. Begin by naming what failed and what state must be recovered.
Choose The Recovery State Before The AWS Service
- An instance or Availability Zone is unavailable, but the data is correct → fail over to a current standby or replica. The priority is continuity with low recovery time.
- Data was deleted, encrypted, or corrupted → restore an earlier snapshot, backup, object version, or point-in-time state. A replica may already contain the same bad change.
- The production account is compromised → recover from a copy controlled by a different account or administrative boundary.
- A Region is unavailable → use data and application recovery resources in another Region.
Two objectives make the tradeoff measurable:
- Recovery Point Objective (RPO) is the acceptable data gap: how far back the newest usable recovery point may be.
- Recovery Time Objective (RTO) is the acceptable outage: how long until the workload is usable again.
Synchronous replication can reduce data loss but adds write latency and does not preserve history. Asynchronous replication reduces coupling and distance constraints, but replication lag can become data loss after promotion. Neither protects against a bad write that successfully replicates.
Do Not Merge Availability, Scaling, And Recovery
These commonly confused controls have different jobs:
- Multi-AZ database deployment → availability through managed standby failover.
- Read replica → read scaling and, in some designs, promotable continuity; it contains a recent copy, not a history of old states.
- Snapshot, backup, or point-in-time recovery (PITR) → return to an earlier state after logical damage.
PITR commonly restores into a new resource. Recovery is therefore a workflow: restore, validate data and dependencies, then deliberately redirect or replace the production resource.
Read deeper about availability, read scaling, and historical recoveryA Complete Recovery Design Has Four Layers
- Continuity: a current standby or replica handles infrastructure failure quickly.
- History: scheduled backups, snapshots, versions, or PITR provide earlier recovery points.
- Isolation: copies cross an authority or location boundary appropriate to the threat.
- Proof: scheduled restore tests show that the data, permissions, dependencies, and runbook actually work within RTO.
AWS Backup can centrally define schedules, retention, and copy actions. A backup vault stores recovery points. A cross-account copy separates administrative authority; a cross-Region copy separates geography. One does not automatically provide the other. Encryption also travels with operational dependencies: recovery needs usable KMS permissions in the recovery boundary.
Immutability Protects Retention, Not Correctness
AWS Backup Vault Lock can prevent recovery points from being deleted before retention ends. Governance mode preserves an escape path for privileged changes; compliance mode becomes immutable after its grace period, even for administrators.
This protects against deletion or retention shortening. It cannot prove that the backup contains correct data, that the application can use it, or that the restore is fast enough. S3 Object Lock is a separate control for S3 object versions, not a universal backup-vault setting.
Read deeper about immutable retentionRestore Testing Is Part Of The Architecture
A successful backup job proves that a copy was created. A restore drill proves much more:
Select recovery point → restore to isolation → start dependencies
→ validate data and application behavior → measure RTO → clean up safely
The drill can expose missing KMS access, broken IAM permissions, absent network dependencies, corrupt application assumptions, and recovery that exceeds the business deadline.
SAA Recognition And Traps
- Fast recovery from infrastructure or AZ failure with correct data → current standby/replica or Multi-AZ failover.
- Recover before an accidental delete or corruption → backup, snapshot, version, or PITR.
- Protect recovery data from a compromised workload account → cross-account copy and separated administration.
- Protect against regional disruption → cross-Region recovery resources and copies.
- Retention must resist administrator deletion → an appropriate Vault Lock mode, understanding that immutability does not validate the backup.
- Prove recovery meets the target → automated restore testing, not backup-success metrics alone.
Do not assume more replicas create historical recovery, a cross-Region copy is automatically cross-account, or a locked but untested backup is usable.
One-Minute Review
Place fails, data correct → current replica / standby
Data wrong → earlier backup / PITR
Authority threatened → cross-account isolation
Region threatened → cross-Region isolation
Deletion threatened → immutable retention
Recovery promised → restore test
If you remember only one thing: a replica helps when the place fails; a backup helps when the data is wrong; isolation protects the copy; testing proves recovery.