Docker Storage

TL;DR

• Containers are ephemeral by design; anything written to the writable layer vanishes when the container is removed
• Docker offers three distinct mount mechanisms: volumes (Docker-managed, portable), bind mounts (host-managed, specific path), and tmpfs (RAM-backed, no persistence)
• Named volumes are preferred for production data because they are portable, backed up easily, and decoupled from host filesystem paths
• Bind mounts are useful for development (mounting source code) but tightly couple containers to specific host paths
• tmpfs mounts are ideal for temporary cache data or sensitive data that should not persist to disk
• Volumes are not automatically deleted when containers are removed; use docker rm -v to delete both container and attached volumes
• The modern storage driver is overlay2, which uses efficient layered filesystems
• Bind-mounting an empty host directory over a path with existing image files hides those files (they are not deleted, just invisible to the container)

Core Concepts

Container Ephemeralness and Data Persistence

By design, containers are ephemeral — any data written to a container’s writable layer is lost when the container is removed. Docker provides three mechanisms to store data that must outlive or bypass the container lifecycle: volumes, bind mounts, and tmpfs mounts.

Named Volumes

Named volumes are Docker-managed storage locations, typically stored in /var/lib/docker/volumes/. Docker handles creation, lifecycle, and cleanup. Volumes are:

• Portable: Not tied to a specific host directory structure; can be moved or replicated to other hosts
• Flexible: Can use volume drivers for network backends (NFS, cloud storage, etc.)
• Decoupled: The container doesn’t need to know the host path; Docker manages the mapping
• Persistent: Not deleted when a container is removed (intentional protection against data loss)

docker run -d -v mydata:/var/lib/mysql mysql:8
docker run -d --mount type=volume,source=mydata,target=/var/lib/mysql mysql:8

Bind Mounts

Bind mounts attach a specific host path directly into the container. They are useful during development (e.g., mounting source code for live editing) but have drawbacks for production:

• Host-dependent: Requires the exact directory structure to exist on the host
• Portable: Harder to replicate across different environments (dev vs production)
• Permission issues: Host filesystem permissions can conflict with container user permissions across different OSes
• Tight coupling: Container setup depends on host configuration

docker run -d -v /home/user/app:/usr/src/app node:20
docker run -d --mount type=bind,source=/home/user/app,target=/usr/src/app node:20

tmpfs Mounts

tmpfs mounts are entirely RAM-backed and never touch disk. They are ideal for:

• Temporary data: Cache, scratch space, build artifacts that don’t need to persist
• Performance: Eliminate disk I/O for paths where speed matters
• Security: Sensitive temporary data that should not touch persistent storage

docker run -d --tmpfs /app/cache:rw,size=64m myapp:1.0

Data in tmpfs is lost when the container stops, which is acceptable (even desirable) for true temporary data.

Storage Drivers and Layered Filesystems

The storage driver determines how Docker’s union filesystem combines image layers into a container’s filesystem view. The storage driver is set at daemon configuration time and affects all containers on that host.

• overlay2: The modern default on virtually all current Linux distributions; uses efficient overlay filesystem for layering
• devicemapper, btrfs, zfs: Legacy or specialized alternatives; rarely used in new deployments
• aufs: Deprecated; no longer supported

Each storage driver has different performance and compatibility characteristics, but overlay2 is the recommended choice for new deployments.

Comparison Table

Aspect	Named Volume	Bind Mount	tmpfs Mount
Managed By	Docker	Host administrator	Docker (in RAM)
Location	/var/lib/docker/volumes/	User-specified path	RAM only
Persistence	Yes (survives container removal)	Yes	No (lost on container stop)
Portability	High (host-independent)	Low (host-dependent)	N/A (temporary)
Performance	Good	Varies by host filesystem	Excellent (RAM)
Use Case	Production databases, persistent state	Development, config mounting	Cache, scratch, sensitive temporary data
Deletion Behavior	Manual delete required	Manual delete required	Auto-deleted on stop
Network Driver Support	Yes (NFS, cloud backends)	No	No

Command Reference

Create a named volume explicitly:

docker volume create mydata

List all volumes on the host:

docker volume ls

Inspect a volume to see its host path and metadata:

docker volume inspect mydata

Remove unused (dangling) volumes:

docker volume prune

Run a container with a named volume:

docker run -d -v mydata:/var/lib/mysql mysql:8

Run a container with a bind mount:

docker run -d -v /home/user/app:/usr/src/app node:20

Run a container with a tmpfs mount (max size 64MB):

docker run -d --tmpfs /app/cache:rw,size=64m myapp:1.0

Mount a volume read-only:

docker run -d -v mydata:/var/lib/mysql:ro mysql:8

Copy files between host and running container without a mount:

docker cp ./config.yaml my-container:/etc/app/config.yaml
docker cp my-container:/var/log/app.log ./app.log

Check disk usage across images, containers, and volumes:

docker system df -v

Find which volumes are currently in use versus orphaned:

docker volume ls -f dangling=true

Remove a container AND its attached volumes:

docker rm -v my-container

Check the storage driver in use:

docker info | grep "Storage Driver"

Common Pitfalls

Pitfall — Volumes Not Auto-Deleted on Container Removal A container is removed with docker rm, but its attached volumes linger on disk, consuming space.

• Why: Volume deletion is intentional protection against accidental data loss; volumes persist independently of container lifecycle.
• Fix: Use docker rm -v to remove both container and attached volumes together, or manually delete specific volumes with docker volume rm.

Pitfall — Bind Mount Path Hides Image Contents A container image has files at /usr/src/app, but after bind-mounting an empty host directory to that same path, those files are invisible and confusingly seem to be “missing.”

• Why: A bind mount completely replaces the mount point’s view; the image’s original files are not deleted but become invisible for the container’s runtime.
• Fix: Either bind-mount to a different path, or ensure the source directory has the content expected in the container (e.g., copy image files to the host directory first).

Pitfall — Named Volumes Tightly Bound to Host Machine Attempting to move or replicate a named volume to another host, discovering that volume drivers make this harder than expected.

• Why: Named volumes are managed by Docker daemon on a specific host; moving them requires exporting the data and importing it elsewhere.
• Fix: For data that must be portable across hosts, use network-based volume drivers (NFS backend) or backup/restore procedures rather than relying on local named volumes.

Pitfall — tmpfs Data Loss on Container Restart Assuming tmpfs data persists across container restarts.

• Why: tmpfs is entirely RAM-backed; stopping the container clears the mount completely.
• Fix: Only use tmpfs for true temporary data (cache, scratch) that does not need to survive container restarts; use named volumes for data requiring persistence.

Interview Questions

Q: Explain the three Docker mount types and their best use cases.

Q: Why are named volumes generally preferred over bind mounts for production data storage?

Q: What is the difference between docker rm and docker rm -v, and when is each appropriate?

Q: A container image has files at /app/data, but binding an empty host directory to /app/data makes those files invisible. Why, and how do you avoid this?

Q: How would you optimize a container that performs heavy disk I/O on temporary cache data using Docker storage options?

Q: Compare the performance and persistence characteristics of named volumes, bind mounts, and tmpfs mounts.

Q: Design a storage strategy for a database container that must survive container restarts but be portable across different hosts.

Q: What is a union filesystem, and how does the storage driver (e.g., overlay2) use it to manage image layers?