Guía práctica de volúmenes Docker: 5 ejemplos para acabar con la pérdida de datos en contenedores

La última línea del terminal decía: «Database import completed successfully». Tras cuatro horas peleándome con ello, por fin importé veinte mil registros de prueba al contenedor MySQL. Probé un par de endpoints de la API y todo pasó.

A la mañana siguiente, como de costumbre, ejecuté docker ps para ver el estado de los contenedores. Vacío. ¿Anoche olvidé arrancarlos? Corrí docker ps -a para ver todos los contenedores. Tampoco aparecían. Entonces recordé: antes de dormir, para liberar espacio en disco, ejecuté docker system prune -a.

Se acabó. Todos los datos, fuera. Veinte mil registros de prueba, cuatro horas de trabajo, reducidos a cero.

Llevaba tres semanas aprendiendo Docker. Sabía que los contenedores arrancan rápido y aíslan bien el entorno, pero no conocía su talón de Aquiles: los contenedores no están pensados para almacenar datos. Eliminas el contenedor y los datos desaparecen; lo reinicias y la configuración vuelve al estado inicial.

En este artículo, con cinco casos prácticos paso a paso, aprenderás a usar Docker Volume (volumen de datos) para sacar los datos del contenedor y que no desaparezcan con su ciclo de vida.

La verdad sobre la pérdida de datos en contenedores

¿Por qué al eliminar el contenedor desaparecen los datos?

Docker usa un sistema de archivos por capas. Imagina un pastel de capas: la capa inferior es la capa de imagen (solo lectura, compartida por todos los contenedores); la capa superior es la capa del contenedor (escritura, exclusiva de cada contenedor). Los archivos que creas, la configuración que modificas y los datos que importas se escriben en esta capa superior.

Aquí está la clave: al eliminar el contenedor, esta capa de escritura se destruye junto con él.

¿No te lo crees? Prueba esto:

# Inicia un contenedor Alpine y escribe un archivo
docker run -it --name test-container alpine sh
# Dentro del contenedor
echo "重要数据" > /tmp/data.txt
exit

# Elimina el contenedor
docker rm test-container

# Intenta recuperar los datos
docker run -it --name test-container alpine sh
cat /tmp/data.txt  # Error: No such file or directory

Los datos desaparecen al instante, sin ninguna advertencia.

Este diseño es bastante razonable: los contenedores están pensados para aplicaciones sin estado. Piensa en Nginx o servidores API: no necesitan guardar datos; cada arranque es igual. Pero ¿bases de datos, Redis o servicios de subida de archivos? Esos sí deben conservar los datos.

La solución oficial de Docker es Volume (volumen de datos): guardar los datos fuera del contenedor y desacoplar por completo la vida del contenedor de la supervivencia de los datos.

¿Qué es Volume? Cómo salva tus datos

La esencia de Volume: el disco duro externo del contenedor

Volume es como conectar un disco duro externo al contenedor. Los datos no se escriben dentro del contenedor, sino en un directorio del host que luego se monta en una ruta interna. El contenedor ve /var/lib/mysql, pero los datos reales están en /var/lib/docker/volumes/mysql-data/_data del host.

¿Eliminaste el contenedor? No pasa nada: los datos siguen en el host. Arrancas otro contenedor, montas el mismo Volume y los datos vuelven.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Docker ofrece tres formas de montaje; al principio es fácil confundirlas:

Al principio yo también confundía Volume y Bind Mount; me parecía que ambos «montaban un directorio del host». Hasta que me equivoqué: monté el directorio de datos de MySQL con Bind Mount, borré el directorio del host por error y el contenedor MySQL se cayó.

Volume lo gestiona Docker por completo: no tienes que preocuparte por rutas, permisos ni estrategia de copias de seguridad. ¿Quieres saber dónde están los datos? Consulta con docker volume inspect. ¿Quieres migrarlos? Los comandos docker volume lo resuelven. Por eso la documentación oficial recomienda Volume en lugar de Bind Mount.

¿Dónde se almacenan realmente los datos del Volume?

En Linux, todos los Volume viven por defecto en:

/var/lib/docker/volumes/<volume-name>/_data/

Si usas Mac o Windows, no busques esa ruta: Docker Desktop corre en una máquina virtual y no la verás directamente. Pero puedes consultar los detalles con docker volume inspect.

5 ejemplos para dominar Volume

Ya está la teoría; vamos a practicar. Estos cinco ejemplos van de lo básico a lo avanzado. Si los sigues uno a uno, lo entenderás de verdad.

Ejemplo 1: crea tu primer Volume con nombre

Empecemos por lo más simple: un Volume vacío.

# Crea un Volume llamado my-data
docker volume create my-data

# Lista todos los Volume
docker volume ls

# Muestra los detalles del Volume
docker volume inspect my-data

Salida esperada (comando inspect):

[
    {
        "CreatedAt": "2025-12-17T12:00:00Z",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/my-data/_data",
        "Name": "my-data"
    }
]

¿Ves Mountpoint? Ahí es donde se guardan realmente los datos.

Ejemplo 2: persistencia de sitio estático con Nginx

Escenario: desarrollas un sitio estático y cada vez que cambias el código reinicias el contenedor Nginx. Pero en cada reinicio desaparecen las imágenes subidas y los logs.

Solución: montar el directorio /usr/share/nginx/html de Nginx en un Volume.

# Crea un Volume para el contenido del sitio
docker volume create nginx-html

# Inicia Nginx montando el Volume
docker run -d \
  --name my-nginx \
  -p 8080:80 \
  -v nginx-html:/usr/share/nginx/html \
  nginx:latest

# Entra al contenedor y crea una página de prueba
docker exec my-nginx bash -c 'echo "<h1>Hello Docker Volume!</h1>" > /usr/share/nginx/html/index.html'

# Prueba el acceso (navegador en http://localhost:8080 o curl)
curl http://localhost:8080

Ahora elimina el contenedor:

docker rm -f my-nginx

Arranca un contenedor nuevo montando el mismo Volume:

docker run -d \
  --name my-nginx-v2 \
  -p 8080:80 \
  -v nginx-html:/usr/share/nginx/html \
  nginx:latest

# Vuelve a acceder: el contenido sigue ahí
curl http://localhost:8080

Los datos no se perdieron. Esa es la magia de Volume.

Ejemplo 3: persistencia de datos con MySQL (nivel práctico)

Es el caso más habitual. Despliegas MySQL en contenedor y los datos deben persistir.

# Crea un Volume dedicado a MySQL
docker volume create mysql-data

# Inicia el contenedor MySQL
docker run -d \
  --name mysql-demo \
  -e MYSQL_ROOT_PASSWORD=my-secret-pw \
  -e MYSQL_DATABASE=testdb \
  -p 3306:3306 \
  -v mysql-data:/var/lib/mysql \
  mysql:8.0

# Espera a que MySQL arranque (unos 10 segundos)
sleep 10

# Conéctate a MySQL y crea una tabla de prueba
docker exec -it mysql-demo mysql -uroot -pmy-secret-pw testdb -e "
CREATE TABLE users (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(50)
);
INSERT INTO users (name) VALUES ('Alice'), ('Bob');
"

# Consulta los datos
docker exec -it mysql-demo mysql -uroot -pmy-secret-pw testdb -e "SELECT * FROM users;"

Ahora elimina el contenedor (simula un borrado accidental):

docker rm -f mysql-demo

Vuelve a arrancar MySQL montando el mismo Volume:

docker run -d \
  --name mysql-demo-v2 \
  -e MYSQL_ROOT_PASSWORD=my-secret-pw \
  -p 3306:3306 \
  -v mysql-data:/var/lib/mysql \
  mysql:8.0

# Espera el arranque
sleep 10

# Consulta los datos: siguen ahí
docker exec -it mysql-demo-v2 mysql -uroot -pmy-secret-pw testdb -e "SELECT * FROM users;"

Punto clave: el directorio de datos de MySQL es /var/lib/mysql; esa es la ruta que debes montar. Cada base de datos usa una ruta distinta: Redis usa /data, PostgreSQL usa /var/lib/postgresql/data.

Ejemplo 4: configuración de persistencia con Redis

Redis guarda los datos en memoria por defecto, pero puedes configurar persistencia en disco (RDB o AOF).

# Crea un Volume para datos de Redis
docker volume create redis-data

# Inicia Redis con persistencia AOF
docker run -d \
  --name redis-demo \
  -p 6379:6379 \
  -v redis-data:/data \
  redis:latest redis-server --appendonly yes
  # --appendonly yes activa persistencia AOF

# Escribe datos de prueba
docker exec -it redis-demo redis-cli SET mykey "Hello Redis Volume"

# Lee los datos
docker exec -it redis-demo redis-cli GET mykey

Elimina el contenedor:

docker rm -f redis-demo

Vuelve a arrancarlo:

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

docker run -d \
  --name redis-demo-v2 \
  -p 6379:6379 \
  -v redis-data:/data \
  redis:latest redis-server --appendonly yes

# Los datos siguen ahí
docker exec -it redis-demo-v2 redis-cli GET mykey

Atención: debes añadir --appendonly yes; si no, Redis solo guarda en memoria y los datos se pierden al reiniciar el contenedor.

Ejemplo 5: Volume compartido entre varios contenedores

Escenario: un contenedor Nginx sirve archivos estáticos y otro contenedor de aplicación genera logs; ambos comparten el mismo Volume.

# Crea un Volume compartido
docker volume create shared-logs

# Inicia el contenedor de aplicación y escribe logs
docker run -d \
  --name app-writer \
  -v shared-logs:/logs \
  alpine sh -c "while true; do echo $(date) >> /logs/app.log; sleep 2; done"

# Inicia Nginx y lee los logs
docker run -d \
  --name log-reader \
  -p 8080:80 \
  -v shared-logs:/usr/share/nginx/html:ro \
  nginx:latest
  # :ro significa montaje de solo lectura (read-only), para evitar que Nginx modifique los logs

# Espera unos segundos a que app-writer escriba logs
sleep 5

# Accede al archivo de log (navegador en http://localhost:8080/app.log)
curl http://localhost:8080/app.log

Puntos clave:

1. Un Volume puede montarse en varios contenedores a la vez
2. El sufijo :ro activa el modo solo lectura y mejora la seguridad
3. En producción puedes usar esta arquitectura de contenedor de recolección de logs + contenedor de aplicación

Comandos de gestión de Volume

Después de los cinco ejemplos seguro te preguntas: «¿cómo veo, elimino o limpio estos Volume?»

Aquí tienes la chuleta completa:

# 1. Crear Volume
docker volume create <volume-name>

# 2. Listar todos los Volume
docker volume ls

# 3. Ver detalles del Volume (incluye la ruta de montaje)
docker volume inspect <volume-name>

# 4. Eliminar un Volume concreto
docker volume rm <volume-name>
# Nota: si un contenedor lo está usando, dará error

# 5. Eliminar todos los Volume sin usar (liberar espacio)
docker volume prune
# Pide confirmación; escribe y para continuar

# 6. Forzar eliminación de Volume sin usar (sin confirmación)
docker volume prune -f

Problema habitual: al eliminar un Volume aparece «volume is in use»

Significa que algún contenedor lo está usando. Solución:

# Ver qué contenedor lo usa
docker ps -a --filter volume=<volume-name>

# Detén y elimina el contenedor primero
docker rm -f <container-name>

# Luego elimina el Volume
docker volume rm <volume-name>

Ver cuánto espacio ocupan los Volume

¿Quieres saber cuánto disco ocupa un Volume? Prueba esto:

# Usuarios Linux/Mac
docker volume inspect <volume-name> --format '{{ .Mountpoint }}' | xargs du -sh

# Ejemplo de salida: 512M    /var/lib/docker/volumes/mysql-data/_data

Bind Mount vs Volume: ¿cuál usar?

Es la duda más común al empezar. Yo también me liaba y los mezclaba sin criterio.

Recuerda una frase: datos de producción con Volume, código de desarrollo con Bind Mount.

En concreto:

Comparación de sintaxis

# Volume (recomendado para datos persistentes)
docker run -v my-volume:/data redis:latest

# Bind Mount (recomendado en desarrollo)
docker run -v /Users/me/code:/app node:latest

# Nueva sintaxis --mount (más explícita, recomendada en producción)
docker run --mount type=volume,source=my-volume,target=/data redis:latest
docker run --mount type=bind,source=/Users/me/code,target=/app node:latest

Árbol de decisión

Ante un caso nuevo, ¿no sabes cuál elegir? Hazte tres preguntas:

1. ¿Los datos deben conservarse a largo plazo?
   Sí → Volume; no → tmpfs

2. ¿Necesitas modificar los datos directamente en el host?
   Sí → Bind Mount; no → Volume

3. ¿Es entorno de producción o de desarrollo?
   Producción → Volume; desarrollo → Bind Mount

Comparación con casos reales

Mi entorno de desarrollo:

# En desarrollo: código con Bind Mount, base de datos con Volume
docker run -d \
  --name dev-app \
  -v $(pwd)/src:/app/src \          # Bind Mount: cambios de código al instante
  -v app-uploads:/app/uploads \     # Volume: archivos subidos por usuarios
  -v postgres-data:/var/lib/postgresql/data \  # Volume: datos de la base de datos
  my-app:dev

Mi entorno de producción:

# En producción: todo con Volume
docker run -d \
  --name prod-app \
  -v app-uploads:/app/uploads \
  -v postgres-data:/var/lib/postgresql/data \
  my-app:latest
# El código ya va empaquetado en la imagen; no hace falta montarlo

Preguntas frecuentes y mejores prácticas

FAQ: trampas que he pisado y cómo resolverlas

P1: ¿Se pierden los datos del Volume?
No. Mientras no ejecutes manualmente docker volume rm, los datos se conservan. Incluso si reinicias el host, siguen ahí.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Pero ojo: docker system prune -a --volumes elimina todos los Volume sin usar. ¡Úsalo con cuidado!

P2: ¿Qué pasa si el Volume no existe al arrancar el contenedor?
Docker lo crea automáticamente. Prueba esto:

# No hace falta docker volume create antes; ejecuta directamente
docker run -d -v auto-created-volume:/data alpine
# Docker crea un Volume llamado auto-created-volume

Aun así recomiendo crearlo manualmente para saber exactamente dónde están los datos.

P3: ¿Cómo hacer copia de seguridad de un Volume?
Método recomendado por la documentación:

# Contenedor temporal que empaqueta los datos del Volume
docker run --rm \
  -v mysql-data:/source \
  -v $(pwd):/backup \
  alpine tar -czf /backup/mysql-backup.tar.gz -C /source .

# Para restaurar
docker run --rm \
  -v mysql-data:/target \
  -v $(pwd):/backup \
  alpine tar -xzf /backup/mysql-backup.tar.gz -C /target

P4: ¿Se puede migrar un Volume entre hosts distintos?
Sí, pero hay que hacerlo manualmente:

1. En el host original: empaqueta los datos del Volume con el método anterior
2. Transfiere el archivo .tar.gz al nuevo host
3. En el nuevo host: crea el Volume y descomprime los datos

Opciones más avanzadas: usar NFS o almacenamiento en la nube como Volume Driver.

P5: ¿Qué es un Volume anónimo? ¿Cómo limpiarlo?
Si no indicas nombre, Docker crea un Volume anónimo:

docker run -d -v /data alpine  # genera un nombre aleatorio tipo a1b2c3d4...

Los Volume anónimos son difíciles de gestionar y ocupan disco fácilmente. Para limpiarlos:

docker volume prune  # elimina todos los Volume sin usar (incluidos anónimos)

Mejor práctica: usa siempre Volume con nombre.

6 mejores prácticas (imprescindibles en producción)

1. Usa siempre Volume con nombre

   # ✓ Buena práctica
   docker run -v mysql-data:/var/lib/mysql mysql:8.0

   # ✗ Mala práctica
   docker run -v /var/lib/mysql mysql:8.0  # Volume anónimo
   

2. Copia de seguridad periódica de datos críticos
   Programa una tarea que respalde cada día los Volume de bases de datos. Perder datos duele; lo sé por experiencia.

3. Usa Docker Compose en proyectos complejos

   # docker-compose.yml
   services:
     db:
       image: mysql:8.0
       volumes:
         - mysql-data:/var/lib/mysql

   volumes:
     mysql-data:
       driver: local
   

4. En producción usa —mount en lugar de -v
   La sintaxis --mount es más explícita y los errores son más claros:

   docker run --mount type=volume,source=mysql-data,target=/var/lib/mysql mysql:8.0
   

5. Limpia periódicamente Volume sin usar
   Una vez al mes:

   docker volume prune
   

6. Datos sensibles: Volume cifrado
   Si el Volume contiene contraseñas o claves, valora cifrado (por ejemplo, partición LUKS).

Conclusión

Volvamos a esa madrugada del principio: si hubiera sabido de Docker Volume, bastaba con un comando:

docker run -d --name mysql-demo -v mysql-data:/var/lib/mysql mysql:8.0

Los datos no habrían desaparecido con el contenedor. Cuatro horas de trabajo y veinte mil registros de prueba habrían quedado a salvo en el host.

Los contenedores Docker son «sin estado» por diseño: es su ventaja y también su límite. Volume existe precisamente para superar ese límite. Te permite disfrutar de la ligereza y el aislamiento del contenedor y, a la vez, guardar datos con tranquilidad.

En este artículo hicimos cinco ejemplos: crear tu primer Volume, persistencia de sitio estático con Nginx, escenarios reales con MySQL y Redis, y Volume compartido entre contenedores. Cubren alrededor del 90 % de lo que necesitas en el día a día.

Ahora te toca a ti. Abre la terminal, crea tu primer Volume, arranca un contenedor MySQL y escribe algunos datos. Elimínalo, vuelve a arrancarlo y mira cómo los datos siguen ahí: en ese momento entenderás de verdad qué es la persistencia de datos.

Y si no quieres volver a pasar el miedo de «perder todo a las tres de la madrugada», guarda este artículo. Algún día puede salvarte.