Docker Volumes & Storage
Persistent Data with Named Volumes
Managing filesystem storage directories managed by Docker daemon.
Interview: Expect questions on volume lifecycle management. You should know how to create, inspect, and prune volumes. Be ready to explain the initialization behavior of named volumes (how they copy existing container folder data into the empty volume) and how to backup or restore a named volume in production.
Introduction
Docker volumes can be created anonymously (which gives them a random alphanumeric hash ID name) or explicitly as Named Volumes. Named volumes have a human-readable identifier, making them much easier to backup, reuse, and inspect.
Under the hood, Docker manages the filesystem directory for named volumes under /var/lib/docker/volumes/<volume_name>/_data.
Why It Matters
Named volumes abstract host filesystem structure. Instead of hardcoding host paths (which differ across Windows, macOS, and Linux), named volumes let you configure uniform, platform-independent storage identifiers.
Real-World Analogy
Think of an anonymous volume like a rented storage locker where the manager throws away the key tag—you only know the locker by its long numeric locker serial number. A named volume is like putting your name on the locker door. It belongs to the system, but you can identify and manage it easily by name.
How It Works
When a container starts with a named volume mount:
- Docker checks if the named volume exists. If not, it creates it.
- If the volume is new, Docker copies files from the target container directory into the new host directory.
- Docker mounts the host directory into the container, exposing the data seamlessly.
Internal Architecture
Named volumes are registered inside Docker's database configuration. The Docker daemon manages the lifecycle of these directories. Even if the container referencing the volume is killed, the volume remains untouched on the host filesystem until explicitly pruned.
Visual Explanation
Practical Example
Here is how to manage named volume lifecycles and bind them to database containers:
Common Mistakes
1. Deleting Active Volumes: Trying to delete a volume that is still bound to a stopped container will throw an error. You must delete the container first.
2. Orphans Leaks: Deleting containers via docker rm <container> does not delete associated volumes. Over time, these orphaned volumes accumulate, consuming gigabytes of host storage.
Quick Quiz
Q1: Which CLI command lists all volumes that are not currently used by any container?
A) docker volume ls --unused
B) docker volume prune (interactive list)
C) docker volume clean
Answer: B — docker volume prune will identify and delete all unused volumes, recovering host space.
Scenario-Based Challenge
Scenario:
You need to upgrade a PostgreSQL container from version 14 to version 15. The database files are stored in a named volume db_vol. How do you execute this safely?
pg_upgrade) since Postgres data directories are not always backward compatible.
Debugging Exercise
Failure Case:
A DevOps engineer runs docker volume create log_data. But when the app writes logs, they get a permission denied error. The host filesystem is set up with strict access.
How would you debug this?
View Solution
Docker creates volume directories as root by default. If the container process runs as a non-root user (e.g. UID 1001), it will lack permission to write to the volume.
Fix: Pre-seed permissions by launching a temporary container as root, running chown -R 1001:1001 /target-path on the volume mount, or using a Dockerfile that sets permissions correctly prior to mounting.
Interview Questions
1. Where are Docker volumes stored physically on the host computer?
On Linux, Docker volumes are stored under /var/lib/docker/volumes/. On macOS and Windows, they reside inside the virtual machine managed by Docker Desktop.
2. How do you backup a named volume if you cannot access /var/lib/docker/volumes directly?
You spin up a temporary lightweight container (like busybox), mount the volume to it, mount a host directory, and run tar to archive the volume files into the host path.
Production Considerations
Implement regular backup cron jobs on your Docker hosts to archive named volumes. Avoid mounting volumes across multiple containers writing to the same files concurrently, as this causes file lock race conditions.