Docker Volumes

After this lesson, you will be able to: Use named volumes and bind mounts correctly, choose between them, and back up persistent data.

Containers are ephemeral; their writable layer disappears on rm. Persistent data lives in volumes.

Prerequisites:Docker Networking

Bind mounts vs named volumes

Bind mount: maps a host directory into the container. `docker run -v /host/path:/container/path`. Path is YOUR responsibility (must exist). Live editing host files from inside container. Great for dev. Named volume: Docker manages the backing storage (usually /var/lib/docker/volumes/<name>/). `docker run -v myvol:/container/path`. Survives container removal. Portable across hosts. Great for production. Both look like a directory inside the container; the difference is who owns the host-side storage.

Volume commands

Lifecycle management for named volumes.

tsx

docker volume create pgdata             # create
docker volume ls                        # list
docker volume inspect pgdata            # where is the data on the host
docker volume rm pgdata                 # delete (DESTRUCTIVE)

# Use it
docker run -d -v pgdata:/var/lib/postgresql/data postgres

# Backup a volume to a tarball
docker run --rm -v pgdata:/data -v $(pwd):/backup alpine tar czf /backup/pgdata.tar.gz /data

# Restore
docker run --rm -v pgdata:/data -v $(pwd):/backup alpine sh -c 'cd / && tar xzf /backup/pgdata.tar.gz'

When to use which

Use bind mount for: dev (live-edit source code into container), one-off scripts that need to write back to host, mounting config files from host. Use named volume for: any production data (databases, uploaded files, search indexes), data you want portable, data you want backed up. Anti-pattern: bind-mounting database data in production. Permission and performance issues, especially on Mac/Windows.

Mount config and secrets as read-only

When a container shouldn't write to a mount, mark it ro.

tsx

docker run -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf:ro nginx
# :ro = read-only inside container

# Useful for:
# - configs the app reads but shouldn't modify
# - shared secrets where modification = bug
# - immutable infrastructure principle (container can't tamper with its config)

Backups

A volume without a backup strategy is a future data-loss incident. Strategies: 1. Snapshot the host filesystem (works on AWS EBS, ZFS, LVM). 2. Database-specific dump tools (pg_dump for postgres) inside a sidecar container, written to a backup volume + uploaded to S3. 3. Restic / Borgmatic for general volume backups to remote storage. Test the RESTORE process at least once a quarter. Backups you've never restored aren't backups.

Common mistakes only experienced engineers avoid

`docker compose down -v` in production by accident, wipes volumes. Bind-mounting Postgres data on Mac/Windows. The filesystem driver is slow + permission-fragile. Forgetting to back up. Volumes are durable but not immortal; disk failures happen. Sharing one volume across many containers without coordination; concurrent writes corrupt data. Mounting host paths with `:rw` when `:ro` would do. Defense in depth.

Quick Check

Why is a named volume preferred over a bind mount for a production Postgres container?

Pick the strongest reason.

←Docker Networking

Back to Docker and Containerization

Docker in Development→