The Essential Guide to Docker Volume Management Commands

Docker volume management commands matter as soon as your container writes data you care about. A container's writable layer disappears when you remove the container, but a Docker volume can keep database files, uploads, cache data, or application state across container rebuilds.

This guide shows you the core docker volume commands, how to attach volumes to containers, and where cleanup commands can surprise you.

What Are Docker Volumes?

Docker volumes are Docker-managed storage objects. They live outside the container's writable layer, usually in a Docker-managed location on the host when you use the default local driver. A named volume remains available after you stop, remove, or recreate the container that used it.

Volumes are useful because they provide:

• Persistence: Data survives container replacement.
• Isolation: Application data is separate from the image and writable layer.
• Driver support: Volume drivers can use local disks, network storage, or platform-specific storage backends.
• Operational clarity: Named volumes are easier to inspect, back up, and reuse than anonymous container layers.

Core docker volume Commands

The docker volume command is the main interface for creating, listing, inspecting, and deleting volumes.

docker volume create

Create a named volume:

docker volume create my-app-data

Create a volume with Docker-generated name:

docker volume create

You can also pass driver options when you use a non-default setup:

docker volume create --driver local my-app-data

docker volume ls

List volumes:

docker volume ls

Show only names:

docker volume ls -q

Filter dangling volumes:

docker volume ls --filter dangling=true

dangling=true means Docker does not see the volume as referenced by a container. It does not mean the data is unimportant.

docker volume inspect

Inspect a volume:

docker volume inspect my-app-data

For a local volume, output looks similar to this:

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

The Mountpoint is useful for troubleshooting, but avoid editing files there directly while containers are using the volume. Let the application or a controlled maintenance container write the data.

docker volume rm

Remove one or more volumes:

docker volume rm my-app-data

Docker will not remove a volume while any container still references it, even if that container is stopped. Find and remove those containers first:

docker ps -a --filter volume=my-app-data
docker rm <container-name-or-id>
docker volume rm my-app-data

This command deletes the volume data. Back it up first if the data matters.

docker volume prune

Prune removes unused local volumes. In current Docker versions, docker volume prune removes unused anonymous volumes by default. Use --all if you also want to remove unused named volumes.

Remove unused anonymous volumes:

docker volume prune

Skip the confirmation prompt:

docker volume prune --force

Remove all unused local volumes, including named volumes:

docker volume prune --all

Use labels to make cleanup safer:

docker volume create --label app=myapp myapp-cache
docker volume prune --filter label=app=myapp

Prune operations permanently delete data. Check what a volume contains before pruning named application data.

Mounting Volumes with Containers

Attach volumes when you create a container. Docker can create the named volume automatically if it does not already exist.

Using -v

docker run --name my-postgres \
  -v pgdata:/var/lib/postgresql/data \
  -d postgres

Here, pgdata is the volume name and /var/lib/postgresql/data is the path inside the container.

Using --mount

--mount is more explicit and easier to read in scripts:

docker run --name my-redis \
  --mount type=volume,source=redisdata,target=/data \
  -d redis

Both forms are valid. Use --mount when you want clearer key-value syntax, especially with extra mount options.

Back Up and Restore a Volume

Docker volumes are persistent storage, but they are not backups. A simple backup pattern is to run a temporary container that mounts the volume and writes an archive to the current directory:

docker run --rm \
  -v my-app-data:/data:ro \
  -v "$PWD":/backup \
  alpine \
  tar czf /backup/my-app-data.tgz -C /data .

Restore into an empty volume:

docker volume create my-app-data-restored

docker run --rm \
  -v my-app-data-restored:/data \
  -v "$PWD":/backup \
  alpine \
  tar xzf /backup/my-app-data.tgz -C /data

For databases, prefer database-native backup tools when consistency matters. A filesystem archive of a live database volume may not be safe unless the database is stopped or supports that backup method.

Best Practices for Docker Volume Management

• Use named volumes for data you plan to keep.
• Label volumes that belong to an application or environment.
• Inspect volumes before deleting or pruning them.
• Back up important volumes outside the Docker host.
• Avoid storing irreplaceable data only in an anonymous volume.
• Test restores, not just backups.
• Use volume drivers when you need storage outside the local Docker host.

Takeaway

Use named Docker volumes for state you want to keep, inspect them before deleting anything, and treat prune as a cleanup command with real data-loss risk. The everyday workflow is simple: create or let Docker create the volume, mount it with docker run, inspect it when troubleshooting, back it up when it matters, and remove it only after no containers reference it.