Volumes & Data Management in Production

Docker Intermediate/Advanced

Chapter 5 · Volumes & Data Management in Production

💽 Volumes & Data Management in Production

Containers are deliberately disposable — a container can be removed and recreated at any time. This chapter covers where data that needs to survive that actually lives, and how to back it up.

Named Volumes

A named volume is storage Docker manages itself, living in Docker's own storage area rather than directly inside the project directory. It's the recommended default for persistent application data — a database's files, uploaded content — and survives container removal entirely, remaining available to be reattached to a new container.

docker run -d --name db -v db-data:/var/lib/mysql mysql:8

Bind Mounts

A bind mount maps a specific host filesystem path directly into the container — full read/write coupling to the actual host filesystem. This is what makes local-development live-reloading work (mounting source code so container-side changes reflect on disk instantly), but it's a real liability in production: tightly coupled to one host's specific filesystem layout, and not portable if that container ever needs to run on a different machine.

# local development — live-reloading source code
docker run -v $(pwd):/app -p 3000:3000 myapp

tmpfs Mounts

A tmpfs mount stores data in the host's memory only — it's never written to disk at all, and its contents vanish the moment the container stops. Right for temporary or sensitive data that genuinely shouldn't persist — a session cache, credentials being processed transiently — a real security benefit (nothing ever touches disk) as well as a performance one.

docker run --tmpfs /app/cache myapp

Named Volume vs. Bind Mount vs. tmpfs

Named Volume / Bind Mount

Both persist to disk. Named volumes are Docker-managed and portable; bind mounts are tied to a specific host path.

tmpfs

Never touches disk at all — lives only in memory, gone the instant the container stops.

	Persists After Container Removal?	Best Fit
Named volume	Yes	Persistent application data (databases, uploads)
Bind mount	Yes (on the host path)	Local development, live-reloading source code
tmpfs	No — memory only	Sensitive/temporary data that must never touch disk

Backup Strategies for Containerized Data

Because a named volume lives in Docker's own managed storage area rather than an obvious project folder, backing it up needs a deliberate step: running a temporary container that mounts both the volume and a host backup directory, then archiving the contents across.

docker run --rm \
  -v db-data:/data \
  -v $(pwd)/backup:/backup \
  alpine tar czf /backup/db-data-$(date +%Y%m%d).tar.gz /data

The same discipline dbsec1-8 established for database backups applies directly here — encrypt the resulting archive before it's stored anywhere, and periodically test that it actually restores, rather than assuming a successful-looking backup command means the data is genuinely recoverable.

Volume Drivers

A volume's actual storage backend is pluggable via volume drivers — local (the default, a directory on the host running the container) is the common case, but a driver plugin can back a volume with network storage (NFS) or a cloud provider's block storage instead. This matters in production deployments spanning multiple hosts, where a named volume needs to be more than just a folder tied to whichever specific machine happened to create it.

💻 Coding Challenges

Challenge 1: Choose the Right Mount Type

For each, recommend a named volume, bind mount, or tmpfs: (a) a PostgreSQL database's data directory in production, (b) source code during local development with live reload, (c) a directory holding decrypted API credentials only for the duration of one request.

Goal: Practice applying this chapter's three-way comparison to concrete scenarios.

→ Solution

Challenge 2: Write a Backup Command

Write the docker run command to back up a named volume called uploads-data into a compressed archive in the current host directory, named with today's date.

Goal: Practice the temporary-container backup pattern this chapter introduced.

→ Solution

Challenge 3: Diagnose Lost Data

A developer's app wrote uploaded files directly into /app/uploads inside a running container — no volume, no bind mount. After redeploying (removing and recreating the container), all uploaded files are gone. Explain what happened.

Goal: Practice recognizing why data written to a container's own writable layer, rather than a volume, doesn't survive container removal.

→ Solution

⚠️ Gotcha: Data Written Directly Into a Container Doesn't Survive It

A container's own writable layer is exactly as disposable as the container itself — any file written there without a volume or bind mount backing that path vanishes the moment the container is removed, even if it was never explicitly deleted by anyone. This is the single most fundamental reason volumes exist at all: never store data that needs to survive inside a container's own filesystem — always mount a named volume (or, for local dev, a bind mount) at any path the application writes data that actually matters to. A related, common practical annoyance with bind mounts specifically: files created inside the container (often as root) can end up with a UID that the host user can't read or write — worth checking early rather than assuming permissions will just line up.

🎯 What's Next

The next chapter is Docker Security — running as non-root, read-only filesystems, scanning images for vulnerabilities, and never baking credentials into an image.