To delete a Docker volume, inspect its contents and container references, then run docker volume rm with its exact name. For a wider cleanup, docker volume prune removes unused anonymous volumes; adding --all includes unused named volumes.
“Unused” describes Docker's container references. It does not tell you whether the data matters. A volume left behind after a deployment may still hold the only copy of a database or uploaded files.
What survives a container restart
A container's writable layer survives a normal stop and restart. It is removed when you delete the container. Volumes store data separately and can remain after the container is removed, depending on the removal command and volume type.
Named volumes have names you choose, such as database_data. Anonymous volumes receive generated names when an image or container configuration requests one without a name. Docker does not create a volume for every container automatically. Bind mounts are different again: they expose a host path and are not removed by docker volume rm.
List volumes and check disk usage
Start with the inventory and Docker's storage summary:
docker volume ls
docker system df -v
Filter the list when looking for a particular application:
docker volume ls --filter name=data
A name filter is useful for discovery, but it can match several projects. Copy the exact name you intend to inspect. Replace volume_name and container_name in the examples below with names from your own inventory.
docker volume inspect volume_name
docker ps -a --filter volume=volume_name
The inspection output includes the driver, labels and mountpoint. Use the container list to identify the application owner and check its deployment configuration. Include stopped containers: stopping a container does not release its reference to a volume.
To list volumes with no container references:
docker volume ls --filter dangling=true
Review those names against old deployments, recovery plans and retained data before deciding what to remove.
Back up data you may need
For a database, use its supported backup or export procedure and check that the result can be restored. Copying database files while writes continue can produce an inconsistent archive. If you use a filesystem backup, stop or quiesce the application according to its recovery procedure first.
For ordinary files, this Bash example mounts the source volume read-only and writes an archive into the current directory:
docker volume inspect volume_name
docker run --rm \
--mount type=volume,src=volume_name,dst=/data,readonly \
--mount "type=bind,src=$(pwd),dst=/backup" \
alpine tar czf /backup/volume-backup.tar.gz -C /data .
Run the archive command only after the inspection succeeds. Docker can create a missing named volume, so a misspelt source name could otherwise produce a backup of an empty volume. Choose a trusted image version suitable for your environment; Docker may pull it if it is absent locally. The archive filename will overwrite an existing file of the same name.
PowerShell also supports $() expressions. Quoting the host path is what matters when it contains spaces. For Linux containers under Docker Desktop, the corresponding bind-mount argument is:
docker run --rm --mount type=volume,src=volume_name,dst=/data,readonly --mount "type=bind,src=$($PWD.Path),dst=/backup" alpine tar czf /backup/volume-backup.tar.gz -C /data .
Confirm that the archive exists, inspect its contents and test restoration to a separate location. Keep a recovery copy away from the Docker host. A backup on the same full or failing disk will not cover loss of that host.
Delete a specific volume
Once you have confirmed the exact target and a usable recovery copy for retained data, remove the volume:
docker volume rm volume_name
This permanently deletes that volume's data. Docker reports the removed name or an error. To delete several reviewed volumes, pass their exact names as separate arguments.
If a container still references the volume, decide whether that container should be retired. Do not remove a working service just to clear the error. For a container you have deliberately decommissioned, the sequence is:
docker stop container_name
docker rm container_name
docker volume rm volume_name
Check every reference first. Another container may share the same volume, and removing the container also discards data in its writable layer.
Prune unused volumes
The Docker volume-prune reference distinguishes these two scopes:
| Command | Removal scope |
|---|---|
docker volume prune
|
Unused anonymous local volumes |
docker volume prune --all
|
Unused anonymous and named local volumes |
Both commands prompt for confirmation. Neither prompt is a detailed preview of the files being deleted. Review the volume inventory and backups before running either command; omitting --force keeps the confirmation step.
There is no supported until=48h filter for docker volume prune. The documented filters are label filters. A creation date from docker volume inspect can help your review, but age alone does not establish that a volume can be discarded.
Docker Compose volume management
Use the supported Compose plugin, invoked as docker compose. Run commands with the same project directory, Compose files and project name used for deployment. The legacy docker-compose command is a separate implementation and should not be assumed interchangeable.
docker compose down
This removes the project's containers and networks while retaining volumes. Anonymous volumes are retained too, but a later up does not automatically reconnect them. Use named volumes or explicit bind mounts for data that must survive deployment changes.
To deliberately remove the project's containers and associated volumes, first review its configuration and back up the persistent services. Then:
docker compose down --volumes
As documented in Compose down, this includes named volumes declared in the Compose file and anonymous volumes attached to its containers. External volumes are never removed by this command. Bind-mounted host directories also remain.
docker compose rm -v service_name removes stopped containers for the named service and their anonymous volumes. It does not delete that service's named volumes. Avoid selecting project volumes through a substring of the project name: similar names can belong to unrelated deployments.