Backup and Restore — Don't Discover This During an Outage

~14 min · data, operations

Level 0Container Curious

0 XP0/36 lessons0/10 achievements

0/120 XP to next level120 XP to go0% complete

Two strategies, both worth knowing

1. Native dump tools (preferred for databases)

For Postgres, MySQL, Mongo — use the database's own dump tool. Logical, portable, version-tolerant. pg_dump, mysqldump, mongodump.

2. Volume snapshot via temp container (works for anything)

Spin a temporary container with the volume and a host directory both mounted, tar the volume into the host directory. Crude, generic, sometimes the only option.

Code

pg_dump backup·bash

# Online dump (no downtime)
docker exec db pg_dump -U postgres app > backups/app-$(date +%Y%m%d).sql

# Restore into a fresh container
docker exec -i db psql -U postgres app < backups/app-20260503.sql

Volume snapshot (any volume)·bash

# Backup
docker run --rm \
  -v pgdata:/source:ro \
  -v $(pwd)/backups:/backup \
  alpine sh -c "cd /source && tar czf /backup/pgdata-$(date +%Y%m%d).tar.gz ."

# Restore
docker run --rm \
  -v pgdata:/target \
  -v $(pwd)/backups:/backup \
  alpine sh -c "cd /target && tar xzf /backup/pgdata-20260503.tar.gz"

External links

Postgres — pg_dump

Exercise

Set up a Postgres container with a named volume. Create some data. Take a backup using pg_dump AND a volume snapshot. Tear the container down, recreate it with a fresh volume, and restore from each backup. Both should work.

Progress

Progress is local-only — sign in to sync across devices.

← PreviousBind Mounts — The Dev Loop Trick 🕸️ Networking & Compose →Custom Networks — DNS by Service Name

Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)

No comments yet — be the first.