Replication keeps a second copy current, which protects against losing a disk, a server or a site. It also copies every mistake and attack within seconds. A backup is a separate, older, protected copy you can go back to. You need both, and they answer different failures.
Myth: "We replicate to another region, so we have backups"
Fact: replication answers the question "what if this location disappears?" A backup answers "what if the data in every location is wrong?"
The AWS disaster recovery guidance makes the point plainly. Continuous replication gives the shortest time to copy your data, but it may not protect against corruption or malicious deletion as well as point-in-time backups do.
Run a small thought experiment. An engineer runs a delete with the wrong filter at 14:02. The replica applies the same delete at 14:02 and a few seconds. You now have two copies of an empty table.
Myth: "Snapshots on the same volume count"
Fact: a snapshot is only useful if it survives the thing that took out the original. If the snapshots live in the same account, controlled by the same credentials, an attacker who owns the account deletes both. Where the snapshots live and who can delete them matters as much as that they exist.
What each tool is good for
- Replication: low RPO after hardware or site failure, fast failover.
- Versioning: undoing overwrites and accidental deletes, if it is switched on before the accident.
- Point-in-time backups: going back to a known good moment before corruption.
- Isolated, immutable copies: surviving a compromised account or ransomware.
Some platforms soften the delete problem. The AWS guidance notes that with S3 replication, by default a delete in the source bucket adds a delete marker only in the source, so the copy in the other region keeps the data. That is helpful, and it is a setting to check, not an assumption.
A short test you can run this week
- Pick one important datastore.
- List every copy of it: replicas, snapshots, exports, cross-region copies.
- For each copy, write down who can delete it and whether that same identity can delete the original.
- Mark any copy that is both recent and out of reach of the primary's credentials.
If no copy passes step four, you have availability, not backup.
Closing the gap
The usual fix is cheap. Keep your replica for speed, then add scheduled point-in-time backups copied to a separate account with delete protection. Our post on immutable backups with object lock covers one way to do that, and how to build a backup and DR strategy covers the wider plan.
Safeguard's compliance and evidence automation can record that backup jobs ran and restores were tested, which makes this gap visible in the same place you track other controls.
Quick check
Is a database standby with synchronous replication a backup?
No. Synchronous replication makes the standby identical to the primary, including any bad change. It is a high availability tool.
Does versioning replace backups?
It covers overwrites and deletes of objects in one bucket. It does not cover account compromise, region loss on its own, or databases.
Sources
Last reviewed: 19 October 2026.
