Managing Docker volumes

Docker & Kubernetes · Docker Storage – Volumes, Bind Mounts and Storage Drivers · Lesson 3 of 4

Create, inspect, share and clean up volumes; a volume outlives its containers until you remove it.

Volumes live independently of containers

flowchart LR
  A["Container web-1"] --> V[("Volume my-vol")]
  B["Container web-2"] --> V
  A -.->|"docker rm web-1"| X["Container gone"]
  V --> K["Volume still there"]

Volumes are fully managed by Docker and are not deleted when a container is removed; several containers can share one volume.
docker run -v my-vol:/data … with a missing volume makes Docker create it.
The VOLUME /data instruction in a Dockerfile creates an anonymous volume (named by a hash) every time a container runs.
To share data across machines, use a volume driver that stores data on NFS or cloud storage.

Commands

Command	Meaning
`docker volume create my-vol`	Create a volume
`docker volume ls`	List volumes
`docker volume inspect my-vol`	Show driver and `Mountpoint` (`/var/lib/docker/volumes/my-vol/_data`)
`docker inspect web`	The `Mounts` section shows which volumes a container uses
`docker volume rm my-vol`	Remove a volume — fails while any container (even stopped) uses it
`docker rm -v web`	Remove a container with its anonymous volumes (named volumes stay)
`docker volume prune`	Remove unused anonymous volumes
`docker volume prune -a`	Remove all unused volumes, named ones included

Common traps

Thinking docker rm also removes named volumes → unused volumes pile up, or you think data is gone while the volume still exists.
Since Docker Engine 23, docker volume prune removes only anonymous volumes by default; add -a to include named volumes. Check carefully before pruning, because deleted data cannot be recovered.

Backing up and restoring a volume

Volumes have no built-in backup command, so the usual pattern is a short-lived container that mounts the volume and writes an archive to a bind-mounted folder:

docker run --rm -v my-vol:/data:ro -v "$(pwd)":/backup busybox:1.36 \
  tar czf /backup/my-vol-2026-01-15.tar.gz -C /data .

docker run --rm -v my-vol:/data -v "$(pwd)":/backup busybox:1.36 \
  tar xzf /backup/my-vol-2026-01-15.tar.gz -C /data

For databases, prefer the database's own dump tool (pg_dump, mysqldump) so the backup is consistent, rather than copying files while the server is writing.

Volumes on shared storage

The built-in local driver can mount NFS or CIFS shares as volumes:

docker volume create --driver local --opt type=nfs \
  --opt o=addr=192.0.2.30,rw --opt device=:/exports/app nfs-app

Plugins from storage vendors and cloud providers add other backends. Shared storage lets a container move to another host and find the same data, which Swarm services need.

Permissions

A volume's files are owned by numeric UIDs. If an image runs as UID 1000 but files were created by root, the app gets "permission denied". Fix it by creating the directory with the right owner in the Dockerfile before declaring the volume, or by running a one-off chown container. Bind mounts have the same issue with host UIDs.

Finding what is unused

docker volume ls -f dangling=true lists volumes no container references.
Labels (docker volume create --label project=shop) make it easy to find a project's volumes later.
In Compose, named volumes are prefixed with the project name, such as shop_db-data, and docker compose down -v removes them together with the containers.

Put important volumes on a separate disk or schedule regular backups; a volume survives container removal but not a failed host disk.