Persistent Storage with Volumes

Containers are ephemeral by default — when a container is removed, its writable layer is deleted. For databases, uploads, configuration, and logs, you need persistent storage. This lesson covers volumes, bind mounts, tmpfs, volume management, backup strategies, and data sharing.

---

Why Persistent Storage Matters

Without volumes:                    With volumes:
+-----------+                       +-----------+
| Container | -- rm --> Data LOST   | Container | -- rm --> Data SAFE
| + data    |                       |   |       |           in volume
+-----------+                       +---+-------+
                                        |
                                   +----v----+
                                   |  Volume  |
                                   +---------+

---

Storage Options Compared

Docker offers three types of storage mounts:

Type	Stored Where	Managed By	Performance	Use Case
Volume	Docker-managed area on host	Docker	Best	Databases, persistent data
Bind mount	Specific host path	You	Good	Development, config files
tmpfs	Host memory only	Docker	Fastest	Secrets, temp data

---

Volumes

Volumes are the recommended way to persist data in Docker. They are managed by Docker and stored in a dedicated area on the host filesystem.

Creating and Using Volumes

# Create a named volume
docker volume create my-data

# Run a container with the volume mounted
docker run -d --name db \
  -v my-data:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=secret \
  postgres:16

# Docker creates the volume automatically if it does not exist
docker run -d --name db2 \
  -v auto-created-vol:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=secret \
  postgres:16

Named vs Anonymous Volumes

# Named volume — easy to reference
docker run -v my-data:/data alpine

# Anonymous volume — Docker generates a random name
docker run -v /data alpine

Best practice: Always use named volumes so you can easily find, back up, and manage them.

Volume Management Commands

# List all volumes
docker volume ls

# Inspect a volume
docker volume inspect my-data

# Remove a volume
docker volume rm my-data

# Remove all unused volumes
docker volume prune

Volume Inspect Output

{
  "CreatedAt": "2026-03-05T10:00:00Z",
  "Driver": "local",
  "Labels": {},
  "Mountpoint": "/var/lib/docker/volumes/my-data/_data",
  "Name": "my-data",
  "Options": {},
  "Scope": "local"
}

---

Bind Mounts

Bind mounts map a specific directory on the host into the container. They are ideal for development workflows where you want live code reloading.

# Mount the current directory into the container
docker run -d --name dev-app \
  -v $(pwd):/app \
  -p 3000:3000 \
  node:20-alpine npm run dev

# Read-only bind mount (container cannot modify host files)
docker run -d \
  -v $(pwd)/config:/app/config:ro \
  my-app:latest

When to Use Bind Mounts

Scenario	Use Bind Mount?
Live code reloading in dev	Yes
Sharing config files	Yes
Production database storage	No (use volume)
CI/CD build context	Sometimes

---

tmpfs Mounts

tmpfs mounts store data in memory only — it is never written to disk and is discarded when the container stops.