Database Backups and Restores
Everyone backs up their database. Almost nobody restores it — until the morning a bad DELETE, a
dropped table, or a dead disk forces the question, and the honest answer is we think we have backups.
That gap between "we have backups" and "we have proven we can get the data back" is where companies
quietly die. A backup you have never restored is not a safety net; it is a hope you wrote to disk.
This guide closes that gap. We'll build the mental model that the restore is the real product and the backup is only its raw material, learn the three ways data actually gets backed up and when each one fits, and walk through the failures that turn a backup strategy into a false sense of security — so the next time it matters, you're running a rehearsed procedure instead of improvising in front of an audience.
How to read this
- In an incident right now and need the data back? Jump to Phase 3: When It Breaks for the restore-day checklist and the failure modes to rule out fast.
- Want backups to stop being a black box? Read in order. Phase 1 reframes what a backup is for, Phase 2 covers the three backup types and point-in-time recovery, Phase 3 covers testing, drills, and the ways it all goes wrong.
The phases
- The Restore Is the Real Thing — the mental model: a backup exists only to be restored, so the restore is the thing you measure and test. RPO and RTO in plain terms, and why "we have backups" is a sentence with no information in it.
- The Three Kinds of Backup — logical dumps versus physical snapshots versus the write-ahead log, what each gives you, and how the WAL unlocks point-in-time recovery so you can rewind to the second before the bad command.
- When It Breaks — the cautionary tale of the backup job that wrote empty files for months, the 3-2-1 rule, and how to automate, verify, and drill the restore so it works the day you need it.
Related: What a Database Is · Transactions and ACID