PART 4 · BACKUP AND RESTORE
Why a Docker volume and a replica are NOT a backup
The Difference Between High Availability and Disaster Recovery
Misconception 1: “My data is stored in a Docker volume”
Misconception 2: “We have a synchronous database replica”
• A Docker volume protects data only from the container itself being recreated (docker rm).
• If the server’s disk fails, or someone runs `docker compose down -v`, or the migration script accidentally executes a `DELETE FROM players` query, the data in the volume will disappear instantly.
• The replica ensures high availability in the event of a physical failure of the primary server.
• But the replica repeats all commands from the master in milliseconds! If you run `DROP TABLE purchases` on the master or corrupt the balances due to a bug, the replica will immediately become just as corrupted.
Two Types of True Backups in PostgreSQL
• Logical backup (pg_dump / pg_dumpall): takes a consistent snapshot of the schema and data at the time of execution (using the MVCC mechanism, without blocking read and write operations by users!). Allows you to restore either the entire database or a single specific table.
• Physical backup + WAL archiving (pg_basebackup, pgBackRest, WAL-G): block-by-block copy of database files + write-ahead log (WAL) stream. Required for large databases (hundreds of GB and TB) and recovery to a specific second in the past (Point-in-Time Recovery, PITR).
How does pg_dump create a dump of a live database without shutting it down? It starts a transaction with the REPEATABLE READ isolation level and sees a consistent snapshot as of the start time.