4.4Backing up and restoring volumes
The essentials in 30 seconds
- Logical dump + volume snapshot, complementary: the dump (portable export) before migration, the snapshot (raw archive of the whole state) before change — in practice: regular dump + snapshot before each operation.
- Back up without stopping: a throwaway container mounts the volume read-only and writes the archive outside the volume — production keeps running during the backup.
- Idir's reflex: an untested backup doesn't exist — restore onto a fresh volume, start a database on it, verify the data.
Threaded mini-case — Idir proves the backup works before upgrading
Idir, junior DevOps in Algiers, must upgrade the production database: before touching anything, he dumps the database to a dated folder and snapshots the volume via a read-only throwaway container, without stopping production. Then he restores onto a test volume, starts a database on it and checks the tables. Fourth milestone of the thread: data is backed up AND restorable, with proof.
Sequel of cases 4.1-4.3 — Idir now protects the data of the exposed services.
1. Two schools: dump or snapshot
The logical dump (export via exec) gives a portable file, ideal before migration. The volume snapshot (utility container archiving the volume) captures the whole state. In practice: regular dump + snapshot before change — like Idir before his upgrade.
Both complement each other: the dump is easy to reread and migrate, the snapshot restores everything identically. Only one of the two is half a backup.
2. Backing up without stopping
Don't stop the database: run a throwaway container mounting the same volume in read mode and writing the archive outside the volume (local folder or remote storage). Production keeps running during the backup — Idir interrupts no service.
Automate and date: scheduled backup, dated archives, defined retention period (dailies + weeklies). Archiving inside the volume itself means losing the backup with it.
3. An untested backup doesn't exist
Ritual: restore onto a fresh volume, start a database on it, verify the data. Without this test, you will discover on D-day that the archive is empty or unreadable. And never restore “just to see” onto the production volume.
Testing is proving: replayed archive, verified tables, then delete the test volume. Idir's backup is only validated after this ritual.
🔎 Concrete example — 🔎 Concrete example — Postgres backup without downtime
Idir's ritual: dump + snapshot, restore on a fresh volume.
docker compose exec bdd pg_dump -U app appdb > backups/appdb-$(date +%F).sql
# snapshot du volume :
docker run --rm -v projet_pgdata:/data:ro -v ./backups:/backup ubuntu:24.04 tar czf /backup/pgdata-$(date +%F).tgz -C /data .
# restauration test :
docker volume create pgdata_test
docker run --rm -v pgdata_test:/data -v ./backups:/backup ubuntu:24.04 tar xzf /backup/pgdata-2026-09-22.tgz -C /dataReading: SQL dump + volume snapshot, restore on a fresh volume.
Lesson: never restore “just to see” onto the production volume.
Section vocabulary
- Dump
- Portable LOGICAL export (replayable file) of the database, ideal before migration.
Simple example: Idir exports his database to a dated file before upgrading.
What it is not: a raw archive of the disk.
Reflex: before migrating: think portable dump.
- Snapshot
- RAW archive of the whole volume state, restoring identically.
Simple example: Idir archives the whole volume before the risky change.
What it is not: a partial export reread by hand.
Reflex: before a change: snapshot the whole state.
- Read-only mount
- Volume mounted READ-ONLY for backup: read without risking writes.
Simple example: Idir's throwaway container reads the volume without being able to modify it.
What it is not: a writable mount exposing the volume.
Reflex: backing up: always mount read-only.
- Test restore
- Replaying the archive on a FRESH VOLUME + verifying data: the only proof.
Simple example: Idir starts a test database and checks the tables before validating.
What it is not: a never-replayed archive.
Reflex: backup done: restore and verify before believing you're protected.
In practice — In practice — Your first tested backup
- Dump your database to ./backups with the date.
- Snapshot the volume via a --rm read-only container.
- Restore onto pgdata_test and start a test database.
- Check the tables, then delete the test volume.
Ready-to-say script — announcing the backup before upgrading (30 s)
“This is Idir: before upgrading, I dumped the database and snapshotted the volume without stopping production, and I replayed the archive on a test volume with the tables verified. If the upgrade fails, we restore in minutes.”
Say before any risky operation: show the verification on the test volume.
Copy-paste template — dump + snapshot + test restore
docker compose exec bdd pg_dump -U app appdb > backups/appdb-$(date +%F).sql
docker run --rm -v projet_pgdata:/data:ro -v ./backups:/backup ubuntu:24.04 tar czf /backup/pgdata-$(date +%F).tgz -C /data .
docker volume create pgdata_test
docker run --rm -v pgdata_test:/data -v ./backups:/backup ubuntu:24.04 tar xzf /backup/pgdata-2026-09-22.tgz -C /dataBefore each upgrade
Like Idir: dump + snapshot just before, tested restore — the operation's safety net.
Daily routine
Scheduled dated dump each day, weeklies kept: frequency follows the cost of a loss.
Off-machine archives
Copy to external disk or encrypted remote storage: a backup on the same disk is not one.
Test restore failing
Good news discovered early: fix the procedure now rather than on disaster day.
✓ Best practices
- Automate and date archives.
- Archive off-volume, on another medium.
- Test each restore on a fresh volume.
✗ Common pitfalls
- Backing up into the volume (lost with it).
- Stopping production to dump (needless).
- Never restoring to test.
Key takeaways
- SQL dump + volume snapshot: complementary.
- Throwaway --rm read-only, prod not stopped.
- Test restore on fresh volume.
- Retention + automation = routine.
48h challenge — apply tomorrow
On your real database: dump + snapshot without stopping, restore onto a fresh volume and verify the data.
- I can dump and snapshot without stopping production.
- I can archive off-volume with retention.
- I can restore onto a fresh volume and verify.
Frequently asked questions
What frequency?
At least daily for a live database, before each migration or upgrade, with retention (dailies + weeklies). Adjust to the cost of data loss.
Where to store archives?
Anywhere but the machine: external disk, encrypted remote storage. A backup on the same disk is not one.
Which backup is valid?