Docker Volumes: Persistent Data Storage

Key Insights

Docker containers are ephemeral by design—all data inside a container disappears when it’s removed, making volumes essential for databases, user uploads, and any stateful application.
Named volumes are the recommended approach for production workloads, while bind mounts excel during local development when you need direct filesystem access.
Volume backup strategies should be automated and tested regularly; a simple docker run --volumes-from command can save you from catastrophic data loss.

The Container Data Problem

Containers are designed to be disposable. Spin one up, use it, tear it down. This ephemeral nature is perfect for stateless applications, but it creates a critical problem: what happens to your database when you update the container? What about user-uploaded files or application logs?

Without proper data persistence, removing a container means losing everything inside it. Let’s see this problem in action:

# Start a container and create some data
docker run -d --name temp-db postgres:15
docker exec temp-db psql -U postgres -c "CREATE DATABASE myapp;"

# Remove the container
docker rm -f temp-db

# Start a new container with the same image
docker run -d --name temp-db postgres:15
docker exec temp-db psql -U postgres -c "\l"
# The myapp database is gone

The database we created vanished because container filesystems are temporary. Docker volumes solve this by providing persistent storage that exists independently of container lifecycles.

Volume Types and Their Use Cases

Docker offers three storage mechanisms, each suited for different scenarios.

Named Volumes are managed entirely by Docker and stored in /var/lib/docker/volumes/ on the host. They’re the recommended approach for production because Docker handles permissions, drivers, and lifecycle management:

# Create a named volume
docker volume create pgdata

# Use it with a container
docker run -d \
  --name postgres-prod \
  -v pgdata:/var/lib/postgresql/data \
  postgres:15

Bind Mounts map a specific host directory into a container. They’re perfect for development when you need real-time file synchronization:

# Mount your local code directory
docker run -d \
  --name dev-app \
  -v $(pwd)/src:/app/src \
  -v $(pwd)/config:/app/config \
  node:18 npm run dev

Changes you make locally appear immediately inside the container—no rebuild required. However, bind mounts expose you to permission issues and aren’t portable across different host operating systems.

tmpfs Mounts store data in the host’s memory, never touching the filesystem. Use them for sensitive temporary data like session tokens or password processing:

docker run -d \
  --name secure-app \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  myapp:latest

Data in tmpfs mounts disappears when the container stops, which is exactly what you want for sensitive temporary information.

Creating and Managing Volumes

Volume management follows a straightforward lifecycle. Create volumes explicitly for better control and documentation:

# Create a volume with a specific driver
docker volume create \
  --driver local \
  --opt type=none \
  --opt device=/mnt/storage/appdata \
  --opt o=bind \
  app-data

# Inspect volume details
docker volume inspect app-data

The inspect command reveals crucial information:

[
    {
        "CreatedAt": "2024-01-15T10:30:00Z",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/app-data/_data",
        "Name": "app-data",
        "Options": {
            "device": "/mnt/storage/appdata",
            "o": "bind",
            "type": "none"
        },
        "Scope": "local"
    }
]

For production systems, use the --mount flag instead of -v because it’s more explicit and fails if the volume doesn’t exist:

docker run -d \
  --name production-app \
  --mount source=app-data,target=/data,readonly=false \
  myapp:latest

Clean up unused volumes regularly to reclaim disk space:

# List all volumes
docker volume ls

# Remove a specific volume
docker volume rm app-data

# Remove all unused volumes
docker volume prune -f

Real-World Patterns: Database Persistence

Databases are the canonical use case for volumes. Here’s a production-ready PostgreSQL setup using Docker Compose:

version: '3.8'

services:
  postgres:
    image: postgres:15
    container_name: app-database
    environment:
      POSTGRES_DB: myapp
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data
      - ./init-scripts:/docker-entrypoint-initdb.d:ro
    ports:
      - "5432:5432"
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser -d myapp"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  postgres-data:
    driver: local
    labels:
      backup: "daily"
      environment: "production"

The volume persists data across container replacements. Let’s verify:

# Start the database
docker-compose up -d

# Create some data
docker-compose exec postgres psql -U appuser -d myapp -c \
  "CREATE TABLE users (id SERIAL PRIMARY KEY, name VARCHAR(100));"
docker-compose exec postgres psql -U appuser -d myapp -c \
  "INSERT INTO users (name) VALUES ('Alice'), ('Bob');"

# Completely remove the container
docker-compose down

# Start a new container
docker-compose up -d

# Data persists
docker-compose exec postgres psql -U appuser -d myapp -c \
  "SELECT * FROM users;"

The data survives because it lives in the postgres-data volume, not in the container’s filesystem.

Multiple containers can share the same volume, enabling patterns like separate application and backup containers:

version: '3.8'

services:
  app:
    image: myapp:latest
    volumes:
      - shared-data:/app/data
  
  backup:
    image: backup-agent:latest
    volumes:
      - shared-data:/data:ro
    environment:
      BACKUP_SCHEDULE: "0 2 * * *"

volumes:
  shared-data:

For backups, use the --volumes-from flag to access another container’s volumes:

# Backup a volume to a tar archive
docker run --rm \
  --volumes-from app-database \
  -v $(pwd)/backups:/backup \
  ubuntu \
  tar czf /backup/postgres-backup-$(date +%Y%m%d).tar.gz \
  /var/lib/postgresql/data

# Restore from backup
docker run --rm \
  --volumes-from app-database \
  -v $(pwd)/backups:/backup \
  ubuntu \
  bash -c "cd /var/lib/postgresql/data && tar xzf /backup/postgres-backup-20240115.tar.gz --strip 1"

For volume migration between hosts, export and import the data:

# On source host
docker run --rm \
  -v postgres-data:/data \
  -v $(pwd):/backup \
  ubuntu tar czf /backup/volume-export.tar.gz -C /data .

# Transfer volume-export.tar.gz to destination host

# On destination host
docker volume create postgres-data
docker run --rm \
  -v postgres-data:/data \
  -v $(pwd):/backup \
  ubuntu tar xzf /backup/volume-export.tar.gz -C /data

Best Practices and Common Pitfalls

Use named volumes in production. They’re portable, manageable, and survive docker-compose down. Anonymous volumes (created without names) are difficult to track and clean up.

Implement proper labeling for automated management:

version: '3.8'

services:
  database:
    image: postgres:15
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:
    driver: local
    labels:
      com.myapp.backup-frequency: "daily"
      com.myapp.retention-days: "30"
      com.myapp.environment: "production"
      com.myapp.service: "database"

Watch for permission issues. Containers often run as non-root users, but volume directories might be owned by root. Fix this by setting ownership explicitly:

FROM node:18

RUN useradd -m -u 1000 appuser
USER appuser

# In docker-compose.yml
volumes:
  - app-data:/app/data
# Then manually: docker run --rm -v app-data:/data ubuntu chown -R 1000:1000 /data

Never use bind mounts in production unless you have a specific requirement. They couple your containers to host filesystem structure and create security risks.

Automate volume cleanup to prevent disk exhaustion:

# Add to cron: daily cleanup of unused volumes older than 24 hours
0 3 * * * docker volume prune -f --filter "until=24h"

Test your backup restoration procedure before you need it. A backup you’ve never restored is just wishful thinking:

#!/bin/bash
# backup-test.sh
BACKUP_FILE="test-restore-$(date +%s).tar.gz"

# Create backup
docker run --rm --volumes-from prod-db \
  -v $(pwd):/backup ubuntu \
  tar czf /backup/$BACKUP_FILE /var/lib/postgresql/data

# Stop production container
docker stop prod-db

# Restore to test container
docker run -d --name test-restore-db \
  -v test-restore-data:/var/lib/postgresql/data \
  postgres:15

docker run --rm --volumes-from test-restore-db \
  -v $(pwd):/backup ubuntu \
  tar xzf /backup/$BACKUP_FILE -C /

# Verify restoration
docker exec test-restore-db psql -U postgres -c "\l"

Docker volumes transform containers from disposable compute units into platforms for stateful applications. Master volume management, implement robust backup strategies, and your containerized databases will be as reliable as traditional deployments—with all the benefits of container orchestration.

The Container Data Problem

Volume Types and Their Use Cases

Creating and Managing Volumes

Real-World Patterns: Database Persistence

Volume Sharing and Backup Strategies

Best Practices and Common Pitfalls

Liked this? There's more.