Hands-on Lab

How Data Persists in Docker with Volumes and Bind Mounts

July 17, 2026 3 min

0 / 9

Cheat sheet

Found it useful? Don't miss the next lab

0:00 / 0:00

We start a container with an anonymous volume: the -v /data flag, with no source before the colon, tells Docker to reserve a volume with a random name on its own and mount it at /data. The process writes a test file before it keeps running in the background.

docker run -d --name demo-anon -v /data alpine sh -c "echo 'dato efimero' > /data/nota.txt && sleep 3600"

I did it

We confirm two things at once: that the file exists inside the container and that Docker registered the mount point as a real volume, not just a loose directory inside the container. The anonymous volume already exists, even though it still has no name to identify it by.

docker exec demo-anon cat /data/nota.txt && docker inspect demo-anon --format '{{range .Mounts}}{{.Type}} -> {{.Destination}}{{end}}'

We create an explicitly named volume with docker volume create. Unlike the anonymous one from the previous step, this volume carries a label (labdata) we can reference from any container, reuse across deployments, and find without digging through random identifiers.

docker volume create labdata

I did it

docker volume ls filtered by name confirms labdata exists and uses the local driver, the one that manages storage directly on this Docker host's disk.

docker volume ls --filter name=labdata --format '{{.Driver}} {{.Name}}'

docker volume inspect reveals where the volume actually lives on the Docker host's filesystem: the Mountpoint field points to a folder under /var/lib/docker/volumes/. That is where Docker really keeps the data, even though you only ever interact with it through the name labdata.

docker volume inspect labdata --format 'Mountpoint: {{ .Mountpoint }}'

I did it

We start the writer container (our 'container A') mounting the named volume with -v labdata:/data: here the source is a volume name, not a path, and Docker resolves it automatically. The process writes a message to /data/mensaje.txt and keeps running.

docker run -d --name writer -v labdata:/data alpine sh -c "echo 'contenido persistente' > /data/mensaje.txt && sleep 3600"

I did it

We read the file directly inside writer to confirm the write actually reached the volume before moving on with the rest of the lab.

docker exec writer cat /data/mensaje.txt

We fully remove the writer container with docker rm -f. This is the important part: we delete the entire container, not just stop it, and yet the labdata volume is not part of that removal because it has its own lifecycle, independent from the container that used it.

docker rm -f writer

I did it

docker ps -a confirms writer no longer exists at all (not running, not stopped) and docker volume ls confirms, in the same breath, that labdata is still there. The container is gone; the volume stayed.

docker ps -a --filter name=writer; docker volume ls --filter name=labdata

This is the key moment of the lab: a brand-new container, one that has never heard of writer, mounts the same labdata volume and reads mensaje.txt without any trouble. The data never lived in the container that wrote it, it lived in the volume, which is why any container that mounts it can read it.

docker run --rm -v labdata:/data alpine cat /data/mensaje.txt

I did it

We first create a real file on the host, outside Docker, then mount that exact folder with -v /opt/labdata-bind:/data. Because the source starts with /, Docker does not create anything new and does not manage that storage: it simply makes a path that already existed on the host visible inside the container.

mkdir -p /opt/labdata-bind && echo "creado en el host" > /opt/labdata-bind/host.txt && docker run --rm -v /opt/labdata-bind:/data alpine cat /data/host.txt

I did it

We write from inside another container and read the result directly on the host, without going through Docker at all. The line the container appended shows up in the host file instantly: there is no copy, no syncing, it is literally the same file seen from two places.

docker run --rm -v /opt/labdata-bind:/data alpine sh -c "echo 'escrito desde el contenedor' >> /data/host.txt" && cat /opt/labdata-bind/host.txt

We repeat the read of the labdata volume, but this time with the --mount type=volume,source=labdata,target=/data syntax instead of -v labdata:/data. It does exactly the same thing, but explicitly: --mount separates type, source and target into key-value pairs, so a misspelled volume name fails with a clear error instead of silently creating a new empty volume, which is the classic -v footgun.

docker run --rm --mount source=labdata,target=/data,type=volume alpine cat /data/mensaje.txt

I did it

We tear down everything the lab created: force-remove the demo-anon container that was still running, explicitly delete the named volume labdata, prune any leftover unused anonymous volumes, and remove the bind-mount folder from the host.

docker rm -f demo-anon; docker volume rm labdata; docker volume prune -f; rm -rf /opt/labdata-bind

I did it

We check all three things separately: docker ps -a no longer lists demo-anon or writer, docker volume ls no longer includes labdata, and the final check confirms the host folder /opt/labdata-bind is gone. The lab leaves nothing persistent behind.

docker ps -a --filter "name=demo-anon" --filter "name=writer"; docker volume ls --filter name=labdata; [ -d /opt/labdata-bind ] && echo 'bind dir aun existe' || echo 'bind dir eliminado'

Was this lab useful? Rate it:

Click to rate this post!

[Total: 0 Average: 0]

Docker volumes, bind mounts, and why persistence matters

A container is ephemeral by design: remove it and its filesystem disappears along with it. Docker volumes solve this by separating data from the container’s lifecycle, a named volume lives independently, managed by Docker itself, until you explicitly delete it with docker volume rm. In this lab we prove it by writing a file from one container, removing that container entirely, and reading the same file back from a brand-new one, no tricks involved.

Three ways to keep data

Docker offers three mechanisms with very different behavior. The named volume lives under Docker’s own control in /var/lib/docker/volumes/ and is referenced by name (-v labdata:/data). The anonymous volume is the same mechanism with no name assigned: Docker gives it a random identifier that is easy to lose track of. The bind mount is different from the ground up, it mounts a path that already exists on the host (-v /host/path:/data) and creates no object Docker manages at all: the container sees literally the same file the host does.

-v versus –mount

The short -v source:target syntax is convenient but ambiguous: get the volume name wrong and Docker silently creates a new one instead of warning you. --mount type=volume,source=labdata,target=/data is more verbose but explicit, it splits type, source and target into key-value pairs and fails with a clear error when something doesn’t add up, which makes it the safer choice for production scripts.

If you already use Docker to self-host services, this same persistent-data pattern shows up almost everywhere: in our Gitea on Docker guide the volume holds the repositories, in the Vaultwarden one it holds the encrypted password vault, and in the Nginx Proxy Manager one it holds the certificates. You can browse the rest of our guides in the Tools category. If you also run Kubernetes, the volume concept has its own equivalent with different rules, and this DigitalOcean guide goes deeper into sharing data between several containers.

FAQ

What is the difference between a named volume and an anonymous one?

Both are real volumes managed by Docker and live in the same place on the host, but the anonymous one gets a random identifier Docker assigns when you create it with -v /path and no name before the colon, while the named one you create explicitly with docker volume create and can reference by that name from any container.

Where does a Docker volume physically store its data?

On the host running the Docker engine, under /var/lib/docker/volumes/<name>/_data. docker volume inspect shows that exact path in the Mountpoint field; you normally don't need to touch it by hand, but knowing it exists helps explain why the volume survives even after you remove the container.

Does docker rm delete the named volume a container was using?

No. docker rm -v only deletes the anonymous volumes tied to that specific container; a named volume is never removed as a side effect of deleting a container, no matter which flags you use. Removing it requires an explicit docker volume rm, which is what we do in the lab's final cleanup.

Cheat sheet

docker run -d --name demo-anon -v /data alpine sh -c "echo 'dato efimero' > /data/nota.txt && sleep 3600"

```
docker volume create labdata
```

docker volume inspect labdata --format 'Mountpoint: {{ .Mountpoint }}'

docker run -d --name writer -v labdata:/data alpine sh -c "echo 'contenido persistente' > /data/mensaje.txt && sleep 3600"

```
docker rm -f writer
```

docker run --rm -v labdata:/data alpine cat /data/mensaje.txt

mkdir -p /opt/labdata-bind && echo "creado en el host" > /opt/labdata-bind/host.txt && docker run --rm -v /opt/labdata-bind:/data alpine cat /data/host.txt

docker run --rm --mount source=labdata,target=/data,type=volume alpine cat /data/mensaje.txt

docker rm -f demo-anon; docker volume rm labdata; docker volume prune -f; rm -rf /opt/labdata-bind

Found it useful? Don't miss the next lab

Subscribe to the newsletter

Docker volumes, bind mounts, and why persistence matters

Three ways to keep data

-v versus –mount

FAQ

What is the difference between a named volume and an anonymous one?

Where does a Docker volume physically store its data?

Does docker rm delete the named volume a container was using?

Cheat sheet