Hands-on Lab

Cómo persisten los datos en Docker con volúmenes y bind mounts

17 de julio de 2026 3 min

0 / 9

Chuleta

¿Te ha servido? No te pierdas el próximo lab

0:00 / 0:00

Arrancamos un contenedor con un volumen anónimo: la opción -v /data, sin ruta de origen delante de los dos puntos, le pide a Docker que reserve él mismo un volumen con un nombre aleatorio y lo monte en /data. El proceso escribe un fichero de prueba antes de quedarse corriendo en segundo plano.

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

Lo hice yo

Comprobamos dos cosas a la vez: que el fichero existe dentro del contenedor y que Docker registró el punto de montaje como un volumen real, no como un directorio suelto del contenedor. El volumen anónimo ya existe, aunque todavía no tenga un nombre que lo identifique.

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

Creamos un volumen con nombre explícito con docker volume create. A diferencia del anónimo del paso anterior, este volumen tiene una etiqueta (labdata) que podemos referenciar desde cualquier contenedor, reutilizar entre despliegues y localizar sin rebuscar entre identificadores aleatorios.

docker volume create labdata

Lo hice yo

docker volume ls filtrado por nombre confirma que labdata existe y usa el driver local, el que gestiona el almacenamiento directamente en el disco de este host Docker.

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

docker volume inspect revela dónde vive realmente el volumen en el sistema de archivos del host Docker: el campo Mountpoint apunta a una carpeta bajo /var/lib/docker/volumes/. Ahí es donde Docker guarda los datos de verdad, aunque tú solo interactúes con ellos a través del nombre labdata.

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

Lo hice yo

Arrancamos el contenedor writer (nuestro «contenedor A») montando el volumen con nombre con -v labdata:/data: aquí el origen es un nombre de volumen, no una ruta, y Docker lo resuelve automáticamente. El proceso escribe un mensaje en /data/mensaje.txt y se queda corriendo.

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

Lo hice yo

Leemos el fichero directamente dentro de writer para confirmar que la escritura llegó al volumen antes de seguir con el resto del lab.

docker exec writer cat /data/mensaje.txt

Eliminamos por completo el contenedor writer con docker rm -f. Esto es lo importante: borramos el contenedor entero, no solo lo paramos, y aun así el volumen labdata no forma parte de esa eliminación porque tiene su propio ciclo de vida, independiente del contenedor que lo usó.

docker rm -f writer

Lo hice yo

docker ps -a confirma que writer ya no existe en absoluto (ni corriendo ni parado) y docker volume ls confirma, en la misma respuesta, que labdata sigue estando ahí. El contenedor se fue; el volumen se quedó.

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

Este es el momento clave del lab: un contenedor totalmente nuevo, que nunca ha oído hablar de writer, monta el mismo volumen labdata y lee mensaje.txt sin ningún problema. Los datos no vivían en el contenedor que los escribió, vivían en el volumen, y por eso cualquier contenedor que lo monte puede leerlos.

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

Lo hice yo

Creamos primero un fichero real en el host, fuera de Docker, y luego montamos esa carpeta exacta con -v /opt/labdata-bind:/data. Como el origen empieza por /, Docker no crea nada nuevo ni gestiona ese almacenamiento: simplemente hace visible dentro del contenedor una ruta que ya existía en el host.

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

Lo hice yo

Escribimos desde dentro de otro contenedor y leemos el resultado directamente en el host, sin pasar por Docker. La línea añadida por el contenedor aparece en el fichero del host al instante: no hay copia ni sincronización, es literalmente el mismo archivo visto desde dos sitios.

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

Repetimos la lectura del volumen labdata, pero esta vez con la sintaxis --mount type=volume,source=labdata,target=/data en vez de -v labdata:/data. Hace exactamente lo mismo, pero de forma explícita: --mount separa el tipo, el origen y el destino en pares clave-valor, así que un nombre de volumen mal escrito falla con un error claro en lugar de crear en silencio un volumen nuevo vacío, que es el fallo típico de -v.

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

Lo hice yo

Recogemos todo lo que creamos en el lab: forzamos la eliminación del contenedor demo-anon que aún seguía corriendo, borramos explícitamente el volumen con nombre labdata, purgamos con prune cualquier volumen anónimo que haya quedado sin usar y eliminamos la carpeta del bind mount del host.

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

Lo hice yo

Comprobamos las tres cosas por separado: docker ps -a ya no lista ni demo-anon ni writer, docker volume ls ya no incluye labdata, y la comprobación final confirma que la carpeta /opt/labdata-bind del host desapareció. El lab no deja nada persistente detrás.

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'

¿Te ha sido útil este lab? Puntúalo:

Click to rate this post!

[Total: 0 Average: 0]

Volúmenes de Docker, bind mounts y por qué importa la persistencia

Un contenedor es efímero por diseño: al eliminarlo, su sistema de archivos desaparece con él. Los volúmenes de Docker resuelven esto separando los datos del ciclo de vida del contenedor, un volumen con nombre vive de forma independiente, gestionado por el propio Docker, hasta que lo borras explícitamente con docker volume rm. En este laboratorio lo comprobamos escribiendo un fichero desde un contenedor, eliminando ese contenedor por completo y leyendo el mismo fichero desde uno nuevo, sin trucos.

Tres formas de guardar datos

Docker ofrece tres mecanismos con comportamientos muy distintos. El volumen con nombre vive bajo el control de Docker en /var/lib/docker/volumes/ y se referencia por nombre (-v labdata:/data). El volumen anónimo es el mismo mecanismo sin un nombre asignado: Docker le pone un identificador aleatorio y es fácil perderle la pista. El bind mount es distinto de raíz, monta una ruta que ya existe en el host (-v /ruta/del/host:/data) y no crea ningún objeto gestionado por Docker: el contenedor ve literalmente el mismo archivo que el host.

-v frente a –mount

La sintaxis abreviada -v origen:destino es cómoda pero ambigua: si te equivocas en el nombre del volumen, Docker crea uno nuevo en silencio en vez de avisarte. --mount type=volume,source=labdata,target=/data es más verbosa pero explícita, separa el tipo, el origen y el destino en pares clave-valor y falla con un error claro si algo no cuadra, lo que la hace preferible en scripts de producción.

Si ya usas Docker para autoalojar servicios, este mismo patrón de datos persistentes aparece en casi todo: en nuestra guía de Gitea con Docker el volumen guarda los repositorios, en la de Vaultwarden guarda la bóveda de contraseñas cifrada y en la de Nginx Proxy Manager guarda los certificados. Puedes ver el resto de guías en la categoría Herramientas. Si además usas Kubernetes, el concepto de volumen tiene un equivalente propio con reglas distintas, y esta guía de DigitalOcean profundiza en cómo compartir datos entre varios contenedores.

Preguntas frecuentes

¿Qué diferencia hay entre un volumen con nombre y uno anónimo?

Ambos son volúmenes reales gestionados por Docker y viven en el mismo sitio del host, pero el anónimo recibe un identificador aleatorio que Docker asigna al crearlo con -v /ruta sin nombre delante de los dos puntos, mientras que el con nombre lo creas tú explícitamente con docker volume create y puedes referenciarlo por ese nombre desde cualquier contenedor.

¿Dónde se guardan físicamente los datos de un volumen de Docker?

En el host que ejecuta el motor Docker, bajo /var/lib/docker/volumes/<nombre>/_data. docker volume inspect muestra esa ruta exacta en el campo Mountpoint; normalmente no necesitas tocarla a mano, pero saber que existe ayuda a entender por qué el volumen sobrevive aunque elimines el contenedor.

¿Elimina docker rm el volumen con nombre que usaba el contenedor?

No. docker rm -v borra únicamente los volúmenes anónimos asociados a ese contenedor concreto; un volumen con nombre nunca se borra como efecto colateral de eliminar un contenedor, sin importar qué opciones uses. Para borrarlo hace falta un docker volume rm explícito, como hacemos en la limpieza final del lab.

Chuleta

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

¿Te ha servido? No te pierdas el próximo lab

Suscríbete a la newsletter

Volúmenes de Docker, bind mounts y por qué importa la persistencia

Tres formas de guardar datos

-v frente a –mount

Preguntas frecuentes

¿Qué diferencia hay entre un volumen con nombre y uno anónimo?

¿Dónde se guardan físicamente los datos de un volumen de Docker?

¿Elimina docker rm el volumen con nombre que usaba el contenedor?

Chuleta