Operations·21 April 2026·5 min read

Backing up a database, and proving it restores

A dump you have never restored is a hypothesis. How to take one, where to keep it, and how to test it without touching production.

Database backups fail differently from file backups. A half-copied world file is obviously broken; a half-consistent dump restores cleanly and is quietly wrong. The tooling exists to avoid that, and it is one flag.

Take a consistent dump

pg_dump --format=custom --no-owner mydb > mydb.dump
mongodump --archive=mydb.archive --gzip --db=mydb

Both read a consistent snapshot rather than the table as it changes under them. Copying the data directory of a running database does not, which is why 'I backed up the folder' is the most common way a backup turns out not to be one.

Keep it somewhere else

An archive on the same storage as the database it protects covers exactly one failure - you dropping your own table. It covers nothing about the disk or the machine. Panel backups are pulled off the machine they protect for that reason.

Restore it somewhere harmless

1. 1.Create an empty database beside the real one.
2. 2.Restore into it.
3. 3.Count some rows and open the application against it if you can.
4. 4.Drop it.

Do this once a quarter and you have a backup. Skip it and you have a file.