Docker Volumes and Storage¶
Containers are ephemeral. Volumes solve data persistence.
Types¶
- Volumes — managed by Docker, preferred
- Bind mounts — host directory, for development
- tmpfs — in memory
Volumes¶
docker volume create mydata docker run -d -v mydata:/var/lib/postgresql/data postgres:16
Backup¶
docker run –rm -v mydata:/src -v $(pwd):/bak alpine tar czf /bak/backup.tar.gz -C /src .
Compose¶
services: db: volumes: - pgdata:/var/lib/postgresql/data - ./init.sql:/docker-entrypoint-initdb.d/init.sql volumes: pgdata:
Storage Best Practices¶
Named volumes are the preferred method for production data — Docker manages them, they are portable between hosts, and they support volume drivers for remote storage (NFS, AWS EBS, Azure Files). Bind mounts map a host directory directly into the container — ideal for development where you need real-time source code synchronization.
For databases, always use named volumes, never bind mounts — performance is better and data survives container recreation. Regularly back up volumes using docker run --rm -v mydata:/src alpine tar czf - and pipe to S3 or other backup storage. In Kubernetes, PersistentVolumeClaims (PVC) with StorageClass are used instead of Docker volumes, which automatically provision disk space as needed.
Volumes = Persistent Data¶
Named volumes for production, bind mounts for development. Back them up!