Persisting data with volumes

A container's writable layer disappears when the container is removed, and writing heavily to it is slow. For data that must persist, such as a database's files, use a volume: storage managed by Docker, living outside any container, mounted at a path inside it.

docker volume create pgdata
docker run -d --name db -v pgdata:/var/lib/postgresql/data postgres:17

Remove and recreate the db container (to upgrade the image, say) with the same -v pgdata:... and the data is still there.

The more explicit --mount syntax says the same thing and is easier to read in scripts: --mount type=volume,src=pgdata,dst=/var/lib/postgresql/data.

Things to know:

• If you mount a volume that doesn't exist, Docker creates it.
• When an empty volume is mounted over a directory that has content in the image, Docker copies that content into the volume first. Handy for seeding config.
• -v /data with no name creates an anonymous volume with a random ID. They're removed along with the container if you used --rm (or docker rm -v); otherwise they linger.
• Volumes can be shared by several containers at once; append :ro to mount read-only.
• docker volume ls, inspect, rm and prune manage them. Removing containers never removes named volumes, which is good for data and bad for disk space.

To back up a volume, mount it into a throwaway container together with a host folder and tar it up. That works the same everywhere, including Docker Desktop, where volume files live inside the VM rather than on your Mac or PC.