What are Docker volumes and how do they differ from bind mounts?
Learn how Docker volumes differ from bind mounts, where each stores data, and when to use volumes, bind mounts, or tmpfs for persistent container storage.
Expected Interview Answer
Docker volumes and bind mounts both persist data outside a container's writable layer, but volumes are stored in a Docker-managed area (/var/lib/docker/volumes) and are fully controlled by Docker, while bind mounts map an arbitrary host path directly into the container.
Volumes are the preferred mechanism because Docker manages their lifecycle, they work identically across hosts and operating systems, and they can be backed by drivers for remote or encrypted storage. Bind mounts depend on the host's exact directory structure and permissions, making them ideal for local development (editing source live) but fragile for portable production deployments. A third option, tmpfs mounts, keeps data only in host memory and never touches disk.
- Persist data beyond a container's lifetime
- Volumes are portable and host-path independent
- Volumes support storage drivers for remote/cloud backends
- Bind mounts enable live code editing in development
- Decouple state from the container's ephemeral filesystem
- Easier backup, migration and sharing between containers
AI Mentor Explanation
A volume is like the official kit room the ground authority manages: bats and pads are stored in a controlled locker with an inventory tag, and any team can draw from it regardless of which pavilion they use. A bind mount is like a player leaving their own bag in a specific corner of a specific dressing room — it works only if that exact room exists on that exact ground, and moving venues breaks the arrangement.
Step-by-Step Explanation
Step 1
Understand the container filesystem
A container's writable layer is discarded when the container is removed, so anything that must survive needs external storage.
Step 2
Create a named volume
Run docker volume create data or let Docker create it on first use; Docker stores it under /var/lib/docker/volumes and manages its lifecycle.
Step 3
Mount the volume
Attach it with -v data:/app/data or the clearer --mount source=data,target=/app/data so the container reads and writes there.
Step 4
Compare with a bind mount
Use -v /host/path:/app/data to map a real host directory; the container sees the host's files directly with host permissions.
Step 5
Choose per environment
Prefer volumes for portable, production state; use bind mounts for local development where you want live source edits reflected instantly.
What Interviewer Expects
- Clear distinction between Docker-managed and host-managed storage
- Knowledge of where volumes live on disk
- When to prefer volumes over bind mounts
- Awareness of tmpfs as a third option
- Correct -v and --mount syntax
Common Mistakes
- Claiming data in the container layer persists after removal
- Thinking volumes and bind mounts are interchangeable in production
- Confusing the -v short syntax argument order for bind mounts
- Forgetting bind mounts inherit host file permissions and ownership
- Assuming volumes can't be shared between multiple containers
Best Answer (HR Friendly)
“Both are ways to keep a container's data alive after the container stops. A volume is storage that Docker manages for you and can move between machines, while a bind mount simply plugs a folder from your own computer into the container, which is handy while developing.”
Code Example
# Create and use a named volume (Docker-managed)
docker volume create app_data
docker run -d --name db \
--mount source=app_data,target=/var/lib/postgresql/data \
postgres:16
# Bind mount a host directory for live development
docker run -d --name web \
--mount type=bind,source="$(pwd)"/src,target=/app/src \
node:20
# Inspect and back up the volume
docker volume inspect app_data
docker run --rm -v app_data:/data -v "$(pwd)":/backup \
busybox tar czf /backup/app_data.tgz -C /data .Follow-up Questions
- What is a tmpfs mount and when would you use it?
- How do you back up and restore a Docker volume?
- Can multiple containers share the same volume safely?
- What are the risks of bind-mounting host directories in production?
- How do volume drivers enable remote or cloud storage?
MCQ Practice
1. Where does Docker store named volumes by default on a Linux host?
Docker manages named volumes under /var/lib/docker/volumes, independent of any container's lifecycle.
2. Which storage option maps an arbitrary host directory directly into a container?
A bind mount maps a specific host path into the container, so it depends on the host's directory structure.
3. Which option keeps data only in host memory and never writes it to disk?
A tmpfs mount stores data in the host's RAM, so it disappears when the container stops and never touches disk.
Flash Cards
Where do Docker volumes live? — In a Docker-managed area on the host (/var/lib/docker/volumes), controlled entirely by Docker.
What defines a bind mount? — It maps a specific host directory path directly into the container, inheriting host permissions.
Which should you prefer in production? — Named volumes — they are portable, host-path independent, and support storage drivers.
When are bind mounts ideal? — Local development, where you want live source-code edits reflected instantly in the container.
What is a tmpfs mount? — In-memory-only storage that never persists to disk, useful for secrets or scratch data.
Continue Learning
Related Interview Questions
What is the difference between a container's writable layer and a persistent volume?
medium
What is Docker and how does containerization differ from virtual machines?
easy
What is a Docker image and how does it differ from a container?
easy
What is a Dockerfile and what are its most important instructions?
medium