Why Persistent Storage Matters
A container's writable layer is deleted along with the container. For databases, uploaded files, or any state that must survive restarts and removals, Docker offers volumes and bind mounts that live outside the container's lifecycle.
Cricket analogy: A team's warm-up drills on the outfield vanish the moment the ground is cleared, but match-winning stats and player records must survive beyond the day's play -- Docker's writable layer is the outfield, volumes are the official scorebook kept off-site.
Named Volumes
Named volumes are managed entirely by Docker and stored under Docker's data directory (e.g. /var/lib/docker/volumes on Linux). They are the recommended way to persist data because Docker handles their location and backup tooling can target them directly.
Cricket analogy: Named volumes are like the BCCI's official archive that manages and stores every match record centrally in its own vault, so any historian or broadcaster can reliably pull footage from that known, well-organized location rather than a random player's personal shelf.
docker volume create db-data
docker volume ls
docker volume inspect db-data
docker run -d --name db -v db-data:/var/lib/postgresql/data postgres:16
# Equivalent long-form syntax:
docker run -d --name db --mount source=db-data,target=/var/lib/postgresql/data postgres:16Bind Mounts
Bind mounts map a specific path on the host filesystem into the container. They are useful for local development (e.g. live-reloading source code) because you control the exact host path.
Cricket analogy: A bind mount is like practicing on your own home ground where you know every blade of grass and control exactly which pitch strip you're using, useful for fine-tuning technique before a tour, unlike a neutral venue you don't control.
docker run -d --name web -v $(pwd)/site:/usr/share/nginx/html:ro nginx
# :ro makes the mount read-only inside the container
docker run -it --rm -v $(pwd):/app -w /app node:20 npm run devBind mounts depend on the host's directory structure existing and being correct, which makes them less portable across machines than named volumes — prefer named volumes for production data.
Removing and Inspecting Volumes
Volumes are not deleted automatically when a container is removed unless you explicitly opt in, which prevents accidental data loss.
Cricket analogy: It's like a player's career stats not being wiped just because they're dropped from the current squad -- the records stay in the archive unless the board explicitly orders them purged, protecting historical data from accidental loss.
docker rm -v db # removes the container AND any anonymous volumes it used
docker volume rm db-data # remove a named volume explicitly (must be unused)
docker volume prune # remove all unused volumes
docker volume inspect db-data # shows Mountpoint on the hostdocker volume prune deletes every volume not currently attached to a container. Always verify with docker volume ls and check which containers reference a volume before pruning in an environment with important data.
tmpfs Mounts
For sensitive or highly transient data that should never touch disk, Docker also supports tmpfs mounts, which store data only in host memory.
Cricket analogy: tmpfs is like a coach scribbling a temporary tactical signal on a whiteboard visible only pitch-side during the over, never written to any permanent scorebook, so sensitive strategy never leaves the dugout's memory.
docker run -d --name cache --tmpfs /app/cache:size=64m myapp:1.0- Named volumes are managed by Docker and are the recommended way to persist production data
- Bind mounts map a host path directly into the container, ideal for local development
- -v host:container:ro or --mount with readonly makes a mount read-only inside the container
- docker volume prune deletes all volumes not attached to any container — use with caution
- tmpfs mounts store data in memory only and never persist to disk
- Volumes survive
docker rmunless you usedocker rm -vor explicitly remove them
Practice what you learned
1. What happens to data in a container's writable layer when the container is removed without a volume?
2. Which storage option is fully managed by Docker and recommended for persisting production database data?
3. What is the main difference between a named volume and a bind mount?
4. What does appending `:ro` to a -v mount flag do?
5. Which command removes all volumes that are not currently attached to any container?
Was this page helpful?
You May Also Like
Environment Variables and Configuration
Learn how to configure containerized applications using environment variables, .env files, and Dockerfile defaults without rebuilding images.
Running and Managing Containers
Learn the core Docker CLI commands to start, inspect, stop, and remove containers, plus how to view logs and execute commands inside a running container.
Docker Compose Basics
Learn how Docker Compose defines and runs multi-container applications from a single YAML file, replacing long manual docker run commands.
Persistent Volumes and Claims
Learn how Kubernetes decouples storage from Pods using PersistentVolumes, PersistentVolumeClaims, and StorageClasses for durable, dynamically provisioned data.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics