6.0 Backups vs replication — they are NOT the same thing

Replication model

model

concurrent writers2

1
write targets: no
conflicts

Safe

One node orders writes, and followers apply them in the same order. This is the only model that can enforce an invariant like username uniqueness, because there is a single place to check it. The cost: writes stop when the leader is unavailable, and failover is the hazard.

The three models differ in one thing: who is allowed to order writes. Everything else — conflict handling, whether you can enforce uniqueness, what a partition does to you — follows from that.

Replicas quickly reflect writes from one node on other nodes. Backups store OLD SNAPSHOTS so you can go back in time.

If you accidentally delete some data, replication doesn't help — the deletion is propagated to the replicas too. You need a backup to restore it.

They're complementary:

Backups are often part of the process of setting up replication (§1.2)
Archiving replication logs can be part of a backup process

Internal snapshots aren't enough either. Some databases maintain immutable snapshots of past states — a kind of internal backup — but this keeps old versions on the same storage medium as the current state. With a large amount of data it's cheaper to keep backups of old data in an object store optimized for infrequently accessed data, and store only the current state in primary storage.