Backup vs replication vs snapshot vs archive

Short answer: replication protects against a machine dying. A snapshot protects against a change you made minutes ago. A backup protects against everything, including the account itself. An archive is not protection at all — it is storage for data you have stopped using.

They get used interchangeably in conversation, and the substitution is expensive, because three of the four fail at the job people assume they are doing.

Replication is not a backup

A replica is a continuously updated copy of your database on another machine. It exists so that when the primary dies, something else can serve traffic within seconds.

It is excellent at that, and it offers no protection whatsoever against the most common cause of data loss, which is someone or something destroying the data on purpose:

DROP TABLE orders;

That statement reaches every replica in milliseconds. Synchronous replication makes it faster. There is no version of replication where the replica declines to replicate a valid command.

The same applies to a bad migration, an application bug writing garbage, an over-broad UPDATE without a WHERE, and ransomware encrypting rows through the application. Replication faithfully reproduces all of it.

Replication answers "is the service up?" Backup answers "can I get the data back?" Those are different questions and you need both. Nothing here argues against running replicas — just against counting one as a backup.

Snapshots are somewhere in between

"Snapshot" means two genuinely different things, which is most of the confusion.

Storage-layer snapshots — LVM, ZFS, EBS, VMware, CSI VolumeSnapshot — are usually copy-on-write. Creating one is near-instantaneous and initially costs almost nothing, because it records only what has changed since. They are wonderful for "I am about to run a risky migration, let me be able to undo it."

Two limits matter:

• They usually share fate with the volume. A copy-on-write snapshot depends on the original blocks. Lose the volume or the storage system and the snapshot goes with it. EBS snapshots go to S3 and survive volume loss — but they live in the same AWS account, which is the blast radius that matters.
• Crash-consistent is not application-consistent. A snapshot of a running database captures the disk as it would look after a power cut. Postgres will usually recover from that; "usually" is doing real work in that sentence. This is why our guides dump databases rather than snapshotting their volumes.

Backup-tool snapshots — restic, Borg, this product — are the other meaning: a named, immutable, point-in-time restore point stored independently of the source. Those are backups, and the shared word is unfortunate.

The test is simple: if the original storage system disappears, does the snapshot still exist? If no, it is a rollback mechanism. If yes, it is a backup.

Archive is a different job entirely

An archive is where data goes when you have finished using it but cannot delete it — closed accounts, completed projects, records held for a retention period.

Two things distinguish it from backup:

• Backups are copies. Archives are often moves. Data is removed from primary storage to reduce cost and clutter. The archive may be the only copy — which means archives themselves need backing up.
• Different access expectations. A backup is sized for restore speed under pressure. An archive is optimised for cost, and retrieval taking hours is acceptable. That is why archive tiers (Glacier, Archive Storage) are cheap, and why using them for backups is a trap: their retrieval delays and minimum-storage-duration charges land exactly when you are trying to recover.

Storing backups in an archive tier to save money often costs more than it saves. See what backup storage actually costs.

The four together

A reasonable production setup uses all of them, for different reasons:

Primary database
  ├── Streaming replica          → the host dies, failover in seconds
  ├── Storage snapshot, hourly   → bad migration, roll back in minutes
  ├── Off-provider backup, daily → deletion, corruption, ransomware, account loss
  └── Archive, yearly            → records you must keep and will not use

Each row covers something the others do not. The failure is not using them — it is stopping after row one or two and believing the job is done.

The question that sorts them

For any copy of your data, ask two things:

1. If I destroy the original right now, on purpose, does this copy still have the old version? No → replication. Yes → keep going.

2. If the account or storage system holding the original disappears, does this copy survive? No → snapshot. Yes → backup.

Most teams that believe they have three backups discover, on running this, that they have one backup and two things that would have died alongside production.

// A backup: independent storage, separate credentials, immutable history.
const snapshot = await client.backup(["./db-dumps"], {
  description: "nightly",
  tags: { type: "db-backup", env: "prod" },
  encryption: {
    keyfilePath: "/secure/lh.keyfile",
    passphrase: process.env.LH_KEYFILE_PASSPHRASE,
  },
});

Common questions

Is RAID a backup? No. RAID protects against a disk failing. It replicates deletion instantly, exactly like database replication.

Is a read replica a backup? No — same reasoning. It is a performance and availability feature.

Are EBS or RDS snapshots backups? Closer than replication, but they live in the same cloud account. They protect against your mistakes, not against losing the account. Treat them as fast rollback and keep an off-provider copy.

Is versioning in S3 a backup? No. See why S3 versioning is not a backup.

Do I still need backups if I have high availability? Yes, and the two are not substitutes. HA keeps the service running. Backups get the data back. An HA cluster with no backups will keep three healthy copies of a dropped table.

Start with the free tier: backupdata.io has 5 GB free, no card, and the 10-minute quickstart gets you to a first verified snapshot today.