Replication & Backups
The problem
A database living on one machine is one hardware failure away from total data loss, and one accidental bad query away from unrecoverable damage — replication protects against the machine failing, and backups protect against the data itself being wrong or deleted.
Why now
Transactions and ACID already established durability as a guarantee for a single machine; replication and backups are what extend that guarantee past a single machine's failure, and file systems and I/O already covered the durable storage mechanism backups fundamentally rely on.
Mental model
Replication keeps a live, continuously updated copy of the database on another machine, so if the primary dies, a replica can take over quickly — it protects against hardware failure, not against bad data, because a mistake gets replicated too. A backup is a frozen snapshot from a point in time, slower to restore from but the only real protection against corrupted or accidentally deleted data, since a bad write hasn't reached an old backup yet.
Requires
- Transactions & ACIDDatabase Engineering
Replication has to preserve the same durability and consistency guarantees a single-machine transaction already provides, just across multiple machines; you need to know what's being preserved before evaluating how well a replication strategy preserves it.
- File Systems & I/OOperating Systems
A backup is fundamentally a durable, persisted copy of data using the same file I/O operations already covered, just applied at the scale of an entire database instead of a single file.
Unlocks
Used in
- Primary-replica database setups for both high availability and read scaling
- Point-in-time recovery from backups after data corruption or accidental deletion
- Disaster recovery planning — how quickly a system can be restored after total data loss
- Understanding why replication alone is not a backup strategy
Projects
- Set up a primary-replica database pair locally, write to the primary, and confirm the write propagates to the replica
- Simulate an accidental bad DELETE query, then restore the database to a point before it happened using a backup
Examples
- A replica can fail over to become the new primary within seconds of a hardware failure, minimizing downtime
- An accidental DROP TABLE replicates to every replica almost instantly — only a backup taken before the mistake can undo it
Resources
Mastery checklist
- I can explain the difference between what replication protects against and what backups protect against
- I can set up basic primary-replica replication
- I can restore a database from a backup to a specific point in time
- I can explain why 'we have replication' is not a sufficient answer to 'do we have backups'