Chapter 49 — Volumes and data: what survives a container's death

In one sentence

A container's writable layer (Chapter 46) disappears the moment the container is removed — a volume is Docker's mechanism for data that needs to outlive any single container, stored OUTSIDE that disposable layer entirely.

Why this matters

"I ran docker rm on my database container and lost all my data" is one of the single most common, most painful real mistakes new Docker users make — and it's entirely, easily avoidable once this model is clear.

How it actually works

   docker volume create mydata          # create a NAMED volume --
                                        # managed by Docker, stored
                                        # OUTSIDE any container's
                                        # writable layer
   docker run -v mydata:/var/lib/postgresql/data postgres  # MOUNT it
                                        # into the container at a
                                        # specific path -- anything the
                                        # container writes there goes
                                        # into the VOLUME, not its
                                        # disposable writable layer

   docker run -v /host/path:/container/path myimage    # a BIND MOUNT --
                                        # maps a SPECIFIC HOST DIRECTORY
                                        # directly into the container
                                        # (useful for local development
                                        # -- edit code on the host, see
                                        # changes immediately inside the
                                        # running container)

   docker volume ls                       # list all named volumes
   docker volume inspect mydata            # where does it actually
                                        # live on the host's disk?
   docker volume rm mydata                  # DELETE it -- and the
                                        # data with it. Deliberately
                                        # separate from removing any
                                        # container.

The mental model that prevents the classic mistake:

   `docker rm <container>`    removes the CONTAINER and its writable
                              layer (Chapter 46). Anything stored ONLY
                              there is GONE.
   `docker volume rm <vol>`    removes the VOLUME, separately, and
                              explicitly. Data in a properly-mounted
                              volume SURVIVES any number of `docker rm`
                              operations on containers that used it --
                              it's a genuinely separate lifecycle,
                              precisely so this can't happen by
                              accident.

Real-world example

   "I ran a database in a container without a volume, then removed the
   container, and lost everything" is a genuinely, extremely common real
   mistake -- so common that Docker's own official documentation
   explicitly, prominently warns about exactly this scenario, and it's
   one of the most frequently asked/answered questions across every
   Docker-related community and support forum. The typical shape: an
   engineer runs `docker run postgres` (or any stateful service) WITHOUT
   a `-v` volume flag during initial exploration or local development,
   accumulates real, valuable data inside the container over hours or
   days of work, then runs a routine `docker rm` (perhaps as part of an
   unrelated cleanup, or to apply an image update) -- and the data,
   having lived ONLY in that container's disposable writable layer, is
   gone, with no warning and no recovery path.
   THE LESSON, and it generalises past Docker specifically: any
   STATEFUL workload running in a container MUST have its actual data
   directory mounted to a volume (or bind mount) from the very first
   time you run it, not added "later, once it matters" -- because by the
   time it obviously matters, the container holding the only copy of the
   data may already be gone.

Try it yourself

# Reproduce the classic mistake, safely, with throwaway data
docker run -d --name nodata alpine sh -c "echo important data > /data.txt; sleep 300"
docker exec nodata cat /data.txt      # it's there
docker rm -f nodata                    # remove the container
docker run --rm alpine cat /data.txt 2>&1 || echo "gone forever -- exactly the mistake"

# Now do it correctly, with a volume
docker volume create demodata
docker run -d --name withdata -v demodata:/storage alpine sh -c "echo important data > /storage/data.txt; sleep 300"
docker exec withdata cat /storage/data.txt
docker rm -f withdata                   # remove the CONTAINER...
docker run --rm -v demodata:/storage alpine cat /storage/data.txt  # ...but
                                        # the data survived, in the volume

docker volume rm demodata

Common mistakes

Running any stateful service without a volume "just for now." By the time it holds real, valuable data, removing the container without one is an easy, catastrophic mistake to make.
Confusing a bind mount with a named volume. A bind mount ties you to a SPECIFIC host path (great for local dev, awkward for portability); a named volume is managed by Docker and more portable across environments.
Forgetting docker volume rm is a SEPARATE, deliberate action. This is a feature, not friction — it's specifically what prevents accidental data loss when cleaning up containers.

Check yourself

What happens to a container's writable-layer data when the container is removed?
What's the difference between a named volume and a bind mount?
Why does Docker require a separate, explicit command to delete a volume, rather than deleting it automatically with its container?