Keep Docker data after a container stops or is removed
Understand writable layers, rescue files from stopped containers, and choose persistent mounts with tested backups.
Stopping a normal container leaves its writable filesystem layer in place. Removing that container deletes the layer. Put durable application state in a named volume, a suitable bind mount, or an external storage service before the application starts writing.
docker volume create appdata
docker run -d --name app \
--mount type=volume,source=appdata,target=/app/data \
myimage:1.2
The application must actually write to /app/data. A mounted directory does not protect files written elsewhere, and a volume does not replace a backup.
Recover files from a stopped container
If the container still exists, docker cp works even when it is stopped:
docker container ls -a
mkdir -p ./rescue
docker cp exited-app:/app/data/. ./rescue/
The /. copies the directory contents into the existing rescue directory. Check the files, ownership, and application-level consistency before removing the original container. This is file recovery, not proof of a valid database backup.
If the container was removed, its writable layer is no longer a supported recovery source through Docker. Look for backups, retained volumes, or application-level replicas. A container started with --rm is automatically removed when it exits, so stopping it has different consequences from stopping an ordinary retained container.
Select storage by its lifecycle
| Storage | Lifetime and access | Common use |
|---|---|---|
| Named volume | Independent of a particular container; managed through Docker | Database and application state |
| Bind mount | Uses the selected daemon-host path | Configuration, shared files, directly managed logs |
| tmpfs | Temporary; contents disappear when stopped | Scratch data, not persistence |
A default local volume is stored with the daemon, including inside Docker Desktop's VM. Volume drivers can have other backends. Linux tmpfs may use swap; avoid promising that it can never touch disk.
Protect databases and upgrades
Use the database's backup and restore procedures, such as an appropriate logical dump or supported physical backup. A live directory copy can be inconsistent. Retain backups outside the original failure domain and test restoration.
Before an image upgrade, verify the storage mount, database compatibility, ownership, and migration procedure. Reusing the same volume prevents automatic deletion; it does not prevent a new application version from changing or corrupting its contents.
FAQ
Is data safe while the container is running? Its writable layer still exists, but accidental removal or host failure can destroy it. A volume plus a tested backup addresses different risks; neither is an absolute guarantee.
Does docker stop delete data? Normally it stops processes while retaining the container and writable layer. Automatic removal with --rm is an important exception, and tmpfs contents are temporary regardless.
What is an anonymous volume? A mount such as -v /app/data, or an image VOLUME declaration without an explicit replacement, can create a volume with a generated name. It is harder to reconnect intentionally after replacement. Anonymous volumes may be removed by --rm, docker rm -v, or volume cleanup; named volumes normally survive ordinary container removal.
Use docker volume ls -f dangling=true to investigate unused volumes. Do not equate “unreferenced” with “safe to delete.”
See Docker volumes, Docker tmpfs mounts, Copying container files.
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan