Volúmenes de Docker frente a bind mounts: dónde viven realmente los datos
Los dos mecanismos de persistencia de Docker se confunden a diario. Uno lo gestiona el motor, el otro expone una carpeta del host, y elegir mal acaba en permisos rotos o datos huérfanos.
Un contenedor es efímero: lo borras y lo que escribió dentro se va con él. Por eso, si quieres que una base de datos, los ficheros de Nextcloud o un archivo de configuración sobrevivan a un docker compose down, hay que declarar explícitamente dónde vive ese dato fuera del contenedor. Docker ofrece dos formas de hacerlo —volúmenes con nombre y bind mounts— y se confunden lo suficiente como para dedicarles un repaso. Los ejemplos que circulan por ahí están probados con Docker 29 sobre Debian 13 y funcionan en cualquier versión reciente.
Volumen con nombre: lo administra Docker
Un volumen con nombre es un área de almacenamiento que gestiona el propio motor de Docker. Tú solo pones el nombre; la ruta la decide él. Al crear sk-demo-vol y montarlo en un contenedor desechable, lo que se escribe dentro acaba en /var/lib/docker/volumes/sk-demo-vol/_data, un directorio al que se puede entrar como root pero que no conviene editar a mano. La prueba de que persiste es sencilla: un contenedor nuevo, montando el mismo volumen, ve exactamente el mismo contenido.
Es la opción por defecto para los datos que gestiona la aplicación: bases de datos, subidas, todo lo que la app escribe por su cuenta. Docker se encarga de la ubicación y de los permisos, y el volumen aguanta un docker compose down. El matiz que se olvida: down -v sí lo borra.
Bind mount: una carpeta del host
Con un bind mount montas una carpeta concreta del servidor dentro del contenedor. Aquí la ruta la eliges tú, y los cambios se ven al instante en los dos lados: lo que escribe el contenedor aparece en el directorio del host sin pasar por la carpeta de Docker. Su caso típico son los ficheros que quieres tocar tú: un traefik.yml, un nginx.conf.
La regla que suele funcionar: volumen con nombre para lo que gestiona la aplicación, bind mount para lo que gestionas tú. En caso de duda, volumen con nombre, que da menos problemas de permisos.
En un fichero de Docker Compose la diferencia se ve en dos líneas: el volumen se declara abajo, en la sección volumes:, y se referencia por nombre; el bind mount es directamente una ruta del host. Añadir :ro al final lo deja en solo lectura, algo sensato para una configuración.
Conviene tener presente un aviso que se repite poco: no montes rutas sensibles del host sin necesidad. Nunca /, ni /etc, ni directorios personales, y sobre todo nunca /var/run/docker.sock. Quien tenga el socket de Docker montado puede levantar contenedores arbitrarios, lo que en la práctica equivale a ser root sobre toda la máquina.
El agujero: los volúmenes anónimos
Si en el -v te olvidas del nombre —-v /data en lugar de -v nombre:/data—, o si la imagen trae una instrucción VOLUME en su Dockerfile, Docker crea un volumen anónimo con un identificador aleatorio. Estos se acumulan sin que nadie los mire y al cabo de unos meses ya no sabes a qué servicio pertenece cada uno. En docker volume ls aparecen como una cadena larga sin nombre legible, mezclados con los que sí nombraste. Poner nombre siempre sale gratis y evita ese desorden.
La decisión pesa sobre todo en producción. Un bind mount mal montado, o un volumen anónimo que sobrevive cuando ya no toca, son fuentes de datos huérfanos y de espacio que se ocupa sin motivo. Nombrar los volúmenes y montar únicamente lo necesario son dos hábitos que ahorran sustos cuando llega el momento de restaurar o de migrar el servidor.
