Home/Learn/Docker/Docker Volumes & Persistence

Docker Volumes & Persistence

Intermediate

Storage

Container filesystems are ephemeral — data is lost when a container is removed. Docker volumes and bind mounts persist data outside the container lifecycle.

Overview

By design, everything written inside a container goes into the writable layer, which is tied to the container's lifecycle. When the container is removed, all data is gone. Docker provides three storage options: Named Volumes (managed by Docker, stored in /var/lib/docker/volumes/ on the host, best for persistent data like databases), Bind Mounts (mount any host directory into the container, best for dev hot-reloading), and tmpfs Mounts (in-memory, not persisted to disk, best for secrets or temp files). Named volumes are the recommended production approach because Docker manages their location, they work across container restarts and recreations, and they can be backed up with docker run --volumes-from.

Named Volumes vs Bind Mounts

Named volumes are Docker-managed and survive container removal. Bind mounts give you direct access to host filesystem paths — great for development (live code reloading) but not portable for production.

bash — named volume vs bind mount

# ── Named Volume ───────────────────────────────────────

# Create a volume

docker volume create postgres-data



# Use it (postgres writes to /var/lib/postgresql/data â†’ saved in volume)

docker run -d \

  --name postgres \

  -v postgres-data:/var/lib/postgresql/data \   # named volume mount

  -e POSTGRES_PASSWORD=secret \

  postgres:16



# Data persists across container removal/recreation:

docker rm -f postgres

docker run -d --name postgres -v postgres-data:/var/lib/postgresql/data postgres:16

# â†‘ same data — the volume still has it



# ── Bind Mount ─────────────────────────────────────────

# Mount current directory into container (hot-reload for dev)

docker run -d \

  --name dev-server \

  -v $(pwd)/src:/app/src \    # host path:container path

  -p 3000:3000 \

  my-app:dev

# Edit src/ on host â†’ changes immediately visible inside container

Volume Commands & Backup

Docker provides full lifecycle management for volumes. Backing up a volume requires running a temporary container that mounts the volume and tars its contents.

bash — volume management and backup

# List volumes

docker volume ls

# DRIVER    VOLUME NAME

# local     postgres-data

# local     redis-data



# Inspect a volume (see where Docker stores it on host)

docker volume inspect postgres-data

# "Mountpoint": "/var/lib/docker/volumes/postgres-data/_data"



# Remove unused volumes (be careful!)

docker volume prune



# ── Backup a volume ────────────────────────────────────

docker run --rm \

  -v postgres-data:/data \                      # mount the volume read-only

  -v $(pwd):/backup \                           # bind mount backup destination

  alpine \

  tar czf /backup/postgres-backup.tar.gz -C /data .



# ── Restore a volume ──────────────────────────────────

docker run --rm \

  -v postgres-data:/data \

  -v $(pwd):/backup \

  alpine \

  tar xzf /backup/postgres-backup.tar.gz -C /data

Storage Decision Tree

Choosing the right storage type is a common interview and real-world decision point.

Storage type decision guide

Do you need persistence past container removal?

â”œ── No  â†’ Use container's writable layer (default)

â”‚         or tmpfs for in-memory temp data

â””── Yes â†’ Do you need to share data between containers

          or survive docker rm?

          â”œ── Yes, production database/state â†’ Named Volume

          â”‚   docker run -v my-vol:/data ...

          â””── Yes, dev hot-reload / host-integrated â†’ Bind Mount

              docker run -v $(pwd)/src:/app/src ...



Named Volumes:

  âœ… Docker-managed (portable, easy backup)

  âœ… Better performance on Linux

  âŒ Harder to directly inspect from host



Bind Mounts:

  âœ… Direct host filesystem access

  âœ… Great for dev (live code reload)

  âŒ Ties container to host path

  âŒ Permission issues on Linux (UID mismatch)

Key Points to Remember

1Container writable layers are ephemeral — data is lost when the container is removed.
2Named volumes are Docker-managed and persist across container restarts and deletions.
3Bind mounts expose host directories into the container — ideal for development.
4tmpfs mounts store data in memory only — useful for secrets and temp files.
5Back up volumes by running a temporary Alpine container that tars the mounted volume.
6Database containers (Postgres, MySQL, Redis) always need a named volume in production.

Interview Questions

What happens to data written inside a container when the container is removed?

When would you use a bind mount vs a named volume?

Ask Aria about Docker Volumes & Persistence

Your personal AI tutor — ask anything about this concept

Revision Status

Personal Notes

Discussion

Loading discussion…

Docker Networking

Docker Compose — Multi-Container Apps