6.1.4.3 Removal Volume Preservation

Removal volume preservation is the behavior where named volumes attached to a container survive that container's removal, since volumes are managed independently of any specific container's lifecycle, in contrast to the container's own writable layer, which is deleted entirely upon removal.

Why Named Volumes Outlive Their Containers

A named volume exists as its own independent resource, simply attached to a container rather than owned exclusively by it — removing the container detaches the volume but does not delete the volume's actual data.

docker run -d --name myapp -v myapp-data:/data myapp:1.0
docker rm -f myapp
docker volume ls

The myapp-data volume still appears in this listing, confirming it survived the container's removal entirely intact.

Reattaching a Preserved Volume to a New Container

Because the volume's data survived, a new container can be created and attached to that same volume, picking up exactly where the previous container's data left off.

docker run -d --name myapp-new -v myapp-data:/data myapp:1.0
docker exec myapp-new ls /data

This confirms the previously stored data is still present, despite the original container that wrote it no longer existing.

Explicitly Removing the Volume As Well, If Intended

If a volume's data genuinely should be deleted along with its container, this needs to be requested explicitly, since the default removal behavior preserves it.

docker rm -v myapp

The -v flag here additionally removes anonymous volumes associated with the container, though named volumes still require explicit removal through docker volume rm to actually delete their data.

Why Removal Volume Preservation Matters

Understanding that named volumes persist independently of any specific container's removal is essential both for confidently recreating containers without fear of losing their data, and for recognizing that genuinely deleting a volume's data requires an explicit, separate step beyond simply removing the container that was using it.