Volumes and Data

A container's writable layer dies with the container. That is the design, not a limitation — it is what makes containers disposable, reproducible, and safe to restart. But real applications have state, and state has to live somewhere else.

Docker gives you three places, and choosing between them is most of what this lesson is.

The three kinds of mount

docker run -v mydata:/var/lib/postgresql/data postgres:17   # named volume
docker run -v "$PWD:/app" node:22 npm test                  # bind mount
docker run --tmpfs /tmp alpine                              # tmpfs

The syntax is confusingly overloaded: -v means a named volume when the left side is a bare name, and a bind mount when it looks like a path. ./data binds; data creates a volume called data. One character of difference, entirely different behaviour.

The container is gone; the data is not. Start a new Postgres against the same volume and the database is exactly as it was.

--mount says what -v means

The newer syntax is verbose and unambiguous, and worth using in anything that outlives a terminal session:

docker run --mount type=volume,source=pgdata,target=/var/lib/postgresql/data postgres:17
docker run --mount type=bind,source="$PWD",target=/app,readonly node:22
docker run --mount type=tmpfs,target=/tmp alpine

Longer, and it removes two real hazards. It states the type instead of inferring it from punctuation. And it fails if a bind source does not exist, where -v silently creates an empty directory — the reason a bind-mounted config file sometimes shows up inside the container as an empty directory with the same name.

Bind mounts are for development

The characteristic development loop:

docker run -d -p 3000:3000 -v "$PWD/src:/app/src" myapp

Edit on the host, the container sees it immediately, the process reloads. No rebuild.

Three things to know before relying on it:

• It is a live window, not a copy. Deleting a file on the host deletes it in the container.
• A mount hides whatever was underneath. Bind-mounting /app over an image that installed node_modules at /app/node_modules makes those dependencies disappear. The usual fix is an anonymous volume over the subdirectory: -v "$PWD:/app" -v /app/node_modules.
• UIDs are numbers, not names. A container running as UID 1000 writing to a host directory owned by a different UID gets permission denied, and the file it does create is owned by a user your host may not have.

Compose has a purpose-built answer to all of this — develop.watch, covered in Docker in Practice.

Backing a volume up

Volumes live under /var/lib/docker, which you should not go rummaging in. The portable approach is a throwaway container with both the volume and a host directory attached:

docker run --rm \
  -v pgdata:/data:ro \
  -v "$PWD":/backup \
  alpine tar czf /backup/pgdata.tar.gz -C /data .

And to restore:

docker run --rm \
  -v pgdata:/data \
  -v "$PWD":/backup \
  alpine sh -c "cd /data && tar xzf /backup/pgdata.tar.gz"

For a database, prefer the database's own tool — pg_dump via docker exec gives you a consistent snapshot, where a file-level copy of a running Postgres may not.

docker system df                  # where the space actually went
docker volume ls -f dangling=true # volumes no container references
docker volume prune               # delete them — read the list first

Next up: networking — how containers reach each other and the outside world.