Cómo gestionar correctamente los volúmenes Docker

Introducción

Gestionar correctamente los volúmenes Docker significa saber qué datos deben sobrevivir a los contenedores, dónde se almacenan, quién puede acceder a ellos, cómo se copian, cómo se restauran y cuándo pueden eliminarse. La persistencia es una de las partes más importantes de Docker porque los contenedores están pensados para poder recrearse. Si los datos importantes permanecen dentro de la capa efímera del contenedor, esa capacidad de recreación se convierte en un riesgo.

El problema suele aparecer cuando una aplicación funciona bien durante meses y nadie necesita preguntarse dónde guarda realmente su información. Después llega una actualización, una migración, una limpieza del host o un fallo del servidor y se descubre que una base de datos, unos archivos subidos por usuarios o una configuración crítica estaban en una ubicación que nadie había documentado.

Docker ofrece varias formas de persistir información. Los named volumes permiten que Docker gestione la ubicación física del almacenamiento. Los bind mounts conectan una ruta concreta del host con el contenedor. Ambos enfoques son útiles, pero no sirven exactamente para lo mismo y no deben elegirse por costumbre.

Además, un volumen no es automáticamente una copia de seguridad. Puede sobrevivir a la eliminación de un contenedor y, aun así, perderse si falla el host, se borra el volumen o se corrompen los datos. Una estrategia de almacenamiento debe separar persistencia, backup y recuperación.

Este artículo explica cómo organizar el almacenamiento persistente en una infraestructura Docker: qué datos deben salir del contenedor, cuándo utilizar named volumes o bind mounts, cómo nombrar e inventariar recursos, qué permisos aplicar, cómo controlar crecimiento, cómo realizar copias, restauraciones y migraciones y cómo retirar volúmenes antiguos sin eliminar información todavía necesaria.

La separación conceptual entre aplicaciones, datos y configuración se desarrolla en cómo separar correctamente aplicaciones, datos y configuración. Aquí ese principio se aplica específicamente a Docker.

Índice

• Por qué Docker necesita persistencia explícita
• Qué es un volumen Docker
• Named volumes, bind mounts y almacenamiento temporal
• Cómo elegir entre named volume y bind mount
• Qué datos deben persistir
• Qué datos no conviene conservar indefinidamente
• Crear una nomenclatura clara
• Declarar volúmenes correctamente en Compose
• Cuándo utilizar volúmenes externos
• Organizar bind mounts en el host
• Usuarios, UID, GID y permisos
• Montajes de solo lectura
• Volúmenes para bases de datos
• Configuración persistente
• Archivos subidos y documentos
• Logs y datos temporales
• Inventariar volúmenes
• Medir capacidad y crecimiento
• Diseñar copias de seguridad
• Conseguir copias consistentes
• Probar restauraciones
• Migrar un volumen a otro host
• Proteger volúmenes durante actualizaciones
• Cuándo compartir un volumen entre contenedores
• Volúmenes y almacenamiento remoto
• Limpiar volúmenes sin perder datos
• Retirar correctamente un volumen
• Auditar volúmenes de una plataforma existente
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Por qué Docker necesita persistencia explícita

Un contenedor debe poder eliminarse y recrearse sin que eso destruya la información importante de la aplicación.

Por eso conviene pensar en dos capas:

• capa reemplazable: imagen y contenedor;
• capa persistente: datos que deben sobrevivir.

Cuando ambas capas se mezclan, la aplicación deja de ser realmente reproducible.

Ejemplo

Contenedor de aplicación
├── código y dependencias
└── reemplazable

Volumen
├── base de datos
├── uploads
└── persistente

La arquitectura correcta permite sustituir el contenedor manteniendo intacto el estado necesario.

Qué es un volumen Docker

Un volumen es un mecanismo de almacenamiento persistente gestionado por Docker y separado de la capa escribible del contenedor.

Puede utilizarse para:

• bases de datos;
• archivos subidos;
• documentos;
• estado de aplicaciones;
• configuración generada;
• datos que deben mantenerse entre recreaciones.

El volumen tiene ciclo de vida propio

Eliminar un contenedor no elimina necesariamente su volumen. Esa independencia es útil, pero también significa que pueden quedar volúmenes huérfanos que nadie sabe si contienen datos todavía necesarios.

Named volumes, bind mounts y almacenamiento temporal

Named volume

Docker administra la ubicación física. El proyecto utiliza un nombre lógico.

volumes:
  datos_db:

Bind mount

Se enlaza una ruta concreta del host:

/srv/datos/portal:/var/lib/app

Almacenamiento temporal

Algunos datos pueden vivir en la capa del contenedor o en almacenamiento temporal porque pueden regenerarse.

La decisión debe depender del tipo de información, no de cuál sintaxis resulte más familiar.

Cómo elegir entre named volume y bind mount

Regla práctica

Para datos internos de una aplicación que no necesitan manipularse directamente desde el host, un named volume suele ser una opción limpia.

Para configuraciones, certificados, archivos que deben administrarse directamente o datos que necesitan una ruta empresarial explícita, un bind mount puede resultar más adecuado.

Qué datos deben persistir

Deben persistir aquellos que no pueden recrearse de forma sencilla a partir de la imagen o de otra fuente.

• bases de datos;
• uploads de usuarios;
• documentos;
• estado de aplicaciones;
• repositorios internos;
• colas persistentes cuando sea necesario;
• datos de configuración generados;
• certificados privados cuando el diseño lo requiera.

Pregunta clave

Si elimino el contenedor y lo creo de nuevo desde cero, ¿qué información necesito conservar para recuperar la función completa?

Qué datos no conviene conservar indefinidamente

No todo lo que escribe un contenedor merece convertirse en estado permanente.

Puede tratarse de:

• cachés;
• temporales;
• archivos de sesión regenerables;
• artefactos de compilación;
• logs con retención limitada;
• descargas que pueden repetirse.

Persistir todo sin criterio aumenta almacenamiento y dificulta distinguir datos críticos de residuos.

Crear una nomenclatura clara

Los nombres deben permitir relacionar un volumen con su proyecto y función.

Ejemplos:

portal_db
portal_uploads
documentos_data
monitorizacion_metrics

Evita nombres como:

volume1
data2
nuevo
final

Dejar que Compose añada contexto

Cuando el volumen pertenece exclusivamente a un proyecto, el nombre generado por Compose puede aportar suficiente contexto.

Nombres explícitos para recursos compartidos

Si un volumen existe fuera del ciclo del proyecto, debe tener un nombre estable y documentado.

Declarar volúmenes correctamente en Compose

La definición debe dejar claro qué servicio utiliza cada almacenamiento.

services:
  db:
    image: postgres
    volumes:
      - datos_db:/var/lib/postgresql/data

volumes:
  datos_db:

Ventaja

El proyecto describe explícitamente que la base de datos depende de almacenamiento persistente.

No ocultar montajes

Los mounts añadidos manualmente fuera de la definición dificultan reproducir el servicio.

Cuándo utilizar volúmenes externos

Un volumen externo existe independientemente del ciclo de Compose.

Puede ser útil cuando:

• varios proyectos necesitan acceder al mismo recurso;
• el almacenamiento se administra de forma separada;
• se quiere evitar que una operación sobre el proyecto gestione el ciclo del volumen;
• los datos preceden al proyecto;
• la infraestructura de almacenamiento tiene responsable propio.

Más independencia implica más documentación

Compose no crea el recurso, por lo que la reconstrucción debe explicar cómo obtenerlo o prepararlo.

Organizar bind mounts en el host

Cuando se utilizan rutas del host, conviene evitar carpetas dispersas.

Una estructura puede ser:

/srv/docker-data/
├── portal/
│   ├── uploads/
│   └── config/
├── documentos/
│   └── data/
└── proxy/
    └── config/

Separar proyecto y datos

La definición de la aplicación puede estar en:

/srv/docker/portal/

mientras los datos residen en:

/srv/docker-data/portal/

Esto permite aplicar políticas diferentes de backup, permisos y crecimiento.

Usuarios, UID, GID y permisos

Un volumen puede estar montado correctamente y seguir siendo inutilizable si los permisos no coinciden con el usuario del proceso dentro del contenedor.

UID y GID

Linux evalúa identificadores numéricos. El nombre de usuario dentro del contenedor puede no coincidir con el del host.

Evitar chmod 777 como solución

Dar permisos completos elimina síntomas, pero amplía innecesariamente el acceso.

Definir propietario esperado

La documentación debe indicar qué UID/GID necesita cada dato cuando sea relevante.

Revisar después de migrar

Copiar datos entre servidores puede conservar o alterar propietarios. La restauración debe comprobar permisos.

Montajes de solo lectura

Si un servicio solo necesita leer un archivo, no debería recibir permiso de escritura.

- ./config/app.conf:/etc/app/app.conf:ro

Puede aplicarse a:

• configuración;
• certificados públicos;
• plantillas;
• datos de referencia.

Reducir permisos limita daños por errores o vulnerabilidades.

Volúmenes para bases de datos

Las bases de datos son uno de los casos más sensibles.

Persistencia obligatoria

Los archivos de datos no deben depender de la capa efímera del contenedor.

No copiar en caliente sin comprender el motor

Copiar directamente archivos mientras una base está escribiendo puede producir una copia inconsistente.

Separar backup lógico y almacenamiento

En muchos casos es conveniente utilizar herramientas propias del motor para exportar datos, además de proteger el almacenamiento subyacente.

Planificar crecimiento

Una base puede aumentar mucho más rápido que el resto del proyecto.

Configuración persistente

No toda configuración debe guardarse en un volumen.

Configuración versionable

Puede estar en el repositorio y montarse en el contenedor.

Configuración generada

Algunas aplicaciones modifican sus propios archivos y necesitan persistencia.

Secretos

No deben confundirse con configuración ordinaria. Necesitan mecanismos de custodia adecuados.

El objetivo es que reconstruir el contenedor no dependa de cambios manuales ocultos.

Archivos subidos y documentos

Los uploads suelen tener un crecimiento acumulativo y una gran importancia para los usuarios.

Identificar ruta

Debe saberse exactamente qué volumen contiene esos archivos.

Separar de cachés

No conviene que uploads permanentes y temporales compartan una misma política de copia.

Medir crecimiento

Una aplicación puede funcionar correctamente mientras su almacenamiento se aproxima al límite.

Logs y datos temporales

Los logs necesitan persistencia suficiente para diagnóstico, pero no conservación ilimitada.

Rotación

Debe existir un límite de tamaño o retención.

Centralización

En plataformas mayores puede enviarse el log fuera del contenedor.

No mezclar con datos críticos

Un volumen de logs lleno no debería impedir a una base de datos seguir escribiendo si la arquitectura puede evitarlo.

Inventariar volúmenes

Un inventario útil debe incluir:

El inventario debe enlazarse con la documentación de la plataforma. Puede apoyarse en cómo documentar una infraestructura basada en Docker.

Medir capacidad y crecimiento

El almacenamiento debe gestionarse por tendencia, no solo por espacio libre actual.

Medir periódicamente

• tamaño actual;
• crecimiento mensual;
• picos;
• espacio libre;
• tiempo estimado hasta el límite.

Identificar grandes consumidores

Una base o directorio de uploads puede explicar casi todo el crecimiento.

Separar capacidad y rendimiento

Mucho espacio libre no garantiza suficientes IOPS o baja latencia.

Este análisis se conecta con cómo planificar el crecimiento de una infraestructura Docker.

Diseñar copias de seguridad

Persistencia no equivale a backup.

Una copia debe sobrevivir a:

• borrado accidental;
• corrupción;
• fallo del host;
• fallo del disco;
• ransomware;
• errores durante una actualización.

Clasificar volúmenes

No todos necesitan copia.

• críticos: copia frecuente;
• importantes: copia periódica;
• regenerables: pueden excluirse;
• temporales: no necesitan backup.

Copia fuera del host

Una copia almacenada únicamente junto al volumen original no protege frente a pérdida completa del servidor.

Conseguir copias consistentes

La forma correcta depende del tipo de dato.

Archivos estáticos

Pueden copiarse directamente si no están cambiando.

Aplicaciones con escritura

Puede ser necesario detener temporalmente el servicio o utilizar un mecanismo de snapshot consistente.

Bases de datos

Conviene utilizar exportaciones o herramientas específicas del motor cuando corresponda.

Validar integridad

Una copia creada sin errores de sistema puede seguir siendo inutilizable a nivel de aplicación.

Probar restauraciones

La restauración debe demostrar que el volumen puede utilizarse de nuevo.

Prueba mínima

1. crear un volumen vacío;
2. restaurar la copia;
3. conectar una instancia de prueba;
4. comprobar permisos;
5. arrancar;
6. validar datos;
7. realizar una prueba funcional.

Registrar tiempo

La duración de restauración forma parte del plan de recuperación.

Migrar un volumen a otro host

La migración debe separar aplicación y datos.

1. identificar volumen y contenido;
2. detener escrituras cuando sea necesario;
3. crear copia consistente;
4. transferir datos;
5. crear almacenamiento de destino;
6. restaurar propietarios y permisos;
7. desplegar aplicación;
8. validar;
9. mantener origen hasta confirmar la migración.

No depender de rutas accidentales

Los bind mounts deben adaptarse a una estructura documentada en el nuevo host.

Comprobar rendimiento

Un destino con almacenamiento más lento puede funcionar técnicamente pero degradar la aplicación.

Proteger volúmenes durante actualizaciones

La imagen nueva puede modificar el contenido persistente.

Antes del cambio

• identificar volúmenes;
• revisar notas de versión;
• confirmar backup;
• comprobar espacio;
• preparar rollback.

Migraciones

Si el formato de datos cambia, volver a la imagen anterior puede no ser suficiente.

La estrategia completa se desarrolla en cómo diseñar una estrategia de actualización de contenedores Docker.

Cuándo compartir un volumen entre contenedores

Compartir almacenamiento puede ser correcto cuando varios componentes pertenecen a una misma aplicación y necesitan acceder a los mismos archivos.

Ejemplo razonable

Un servicio web y un worker que procesan los mismos uploads.

Riesgo

Dos aplicaciones independientes modificando libremente el mismo volumen crean acoplamiento.

Definir permisos

Un contenedor puede necesitar solo lectura mientras otro necesita escritura.

El volumen compartido debe tener propietario funcional claro.

Volúmenes y almacenamiento remoto

Cuando los datos crecen o deben compartirse entre hosts, puede aparecer almacenamiento remoto.

La decisión debe considerar:

• latencia;
• rendimiento;
• disponibilidad de red;
• bloqueos;
• semántica del sistema de archivos;
• copias;
• permisos;
• recuperación.

No todo volumen funciona igual sobre red

Una base de datos puede tener requisitos diferentes a un directorio de documentos.

La red se convierte en dependencia

Si el almacenamiento remoto falla, el contenedor puede seguir ejecutándose pero perder acceso a sus datos.

Limpiar volúmenes sin perder datos

Los comandos de limpieza deben utilizarse con prudencia.

Volumen “no usado” no significa “sin valor”

Puede pertenecer a un proyecto detenido, una aplicación retirada temporalmente o una restauración pendiente.

Antes de borrar

• identificar nombre;
• revisar etiquetas;
• buscar proyecto asociado;
• inspeccionar contenido cuando sea necesario;
• comprobar inventario;
• confirmar backup;
• documentar retirada.

Prune no sustituye al inventario

La automatización de limpieza solo es segura cuando los recursos están bien clasificados.

Retirar correctamente un volumen

Eliminar un proyecto no implica borrar automáticamente sus datos.

1. confirmar que la aplicación está retirada;
2. determinar requisitos de retención;
3. crear exportación final si procede;
4. revocar accesos;
5. desconectar el volumen;
6. mantener una cuarentena temporal si existe duda;
7. eliminar cuando la retención lo permita;
8. actualizar inventario.

Datos históricos

Puede ser necesario conservarlos sin mantener el servicio activo.

Auditar volúmenes de una plataforma existente

Si la plataforma ya está funcionando y no existe inventario, conviene auditar en modo lectura.

1. Enumerar volúmenes

Crear una lista completa.

2. Relacionar con contenedores

Identificar qué proyectos los montan.

3. Clasificar contenido

• base de datos;
• uploads;
• configuración;
• logs;
• caché;
• desconocido.

4. Medir tamaño

Detectar grandes consumidores.

5. Revisar copias

Comprobar qué volúmenes están protegidos.

6. Detectar huérfanos

No eliminarlos todavía.

7. Investigar desconocidos

Un volumen sin documentación debe considerarse pendiente de clasificación, no basura.

8. Actualizar inventario

Cada recurso debe terminar con proyecto, contenido, criticidad y política de copia conocidos.

Errores frecuentes

Guardar datos dentro del contenedor

Puede provocar pérdida al recrearlo.

No saber qué contiene cada volumen

Hace peligrosas las limpiezas y migraciones.

Usar bind mounts en rutas improvisadas

Reduce portabilidad y dificulta copias.

Aplicar chmod 777

Soluciona síntomas a costa de ampliar permisos.

No controlar UID y GID

Puede romper restauraciones o migraciones.

Compartir un volumen entre aplicaciones independientes

Crea acoplamiento y problemas de permisos.

Confundir persistencia con backup

El volumen puede desaparecer junto con el host.

Copiar bases de datos activas sin procedimiento

Puede generar copias inconsistentes.

No probar restauraciones

La copia puede existir y no ser utilizable.

No medir crecimiento

El primer aviso puede ser un disco lleno.

Persistir logs sin límite

Puede consumir todo el almacenamiento.

Borrar volúmenes con prune sin inventario

Puede eliminar datos todavía necesarios.

Eliminar datos al retirar el contenedor

El ciclo de retención de datos puede ser distinto.

No documentar volúmenes externos

Hace que la reconstrucción del proyecto quede incompleta.

No comprobar permisos tras migrar

Los datos pueden estar presentes pero la aplicación no poder utilizarlos.

Lista de comprobación

• ¿Todos los datos importantes están fuera de la capa efímera?
• ¿Se sabe qué datos deben persistir?
• ¿Se distingue entre named volumes y bind mounts?
• ¿Cada elección tiene una razón?
• ¿Los volúmenes tienen nombres comprensibles?
• ¿Los bind mounts utilizan rutas organizadas?
• ¿La definición Compose declara todos los mounts necesarios?
• ¿Los volúmenes externos están documentados?
• ¿Se conocen UID y GID relevantes?
• ¿Los permisos son mínimos?
• ¿Se utilizan montajes de solo lectura cuando procede?
• ¿Las bases de datos tienen persistencia controlada?
• ¿Los uploads están identificados?
• ¿Los logs tienen retención?
• ¿Existe inventario de volúmenes?
• ¿Se conoce el contenido de cada volumen?
• ¿Se ha clasificado su criticidad?
• ¿Se mide tamaño y crecimiento?
• ¿Los datos críticos tienen copia externa?
• ¿Las copias son consistentes?
• ¿Se han probado restauraciones?
• ¿Existe procedimiento de migración?
• ¿Las actualizaciones protegen los datos?
• ¿Los volúmenes compartidos tienen propietario claro?
• ¿Los recursos huérfanos se investigan antes de borrarse?
• ¿La retirada respeta la política de retención?

Preguntas frecuentes

Conclusión

Gestionar correctamente los volúmenes Docker significa separar de forma consciente la aplicación reemplazable de los datos que deben sobrevivir.

Named volumes y bind mounts son dos herramientas distintas. Los primeros reducen dependencia de rutas del host y encajan bien con datos internos de aplicaciones. Los segundos permiten controlar ubicaciones concretas y son útiles para configuraciones y archivos que deben administrarse directamente. La elección debe responder al ciclo de vida del dato.

Persistencia y backup son conceptos diferentes. Un volumen protege frente a la recreación del contenedor, pero no frente a pérdida del host, corrupción o borrado. Los datos críticos necesitan copias independientes y restauraciones probadas.

La gestión también exige inventario. Cada volumen debe tener una finalidad, un proyecto, una criticidad y una política de retención. Cuando aparece un volumen huérfano, la respuesta correcta no es eliminarlo automáticamente, sino investigar qué contiene.

Permisos, UID y GID son parte del diseño. Una restauración correcta no consiste únicamente en recuperar bytes: la aplicación debe poder volver a leerlos y escribirlos con los permisos adecuados.

El crecimiento del almacenamiento debe medirse con anticipación. Bases de datos, uploads y logs tienen comportamientos distintos y no deberían competir sin control por el mismo recurso.

Finalmente, una plataforma Docker madura debe poder mover sus datos. Si un volumen puede copiarse, restaurarse y vincularse a una nueva instancia sin depender del host original, la infraestructura gana capacidad real de recuperación y evolución.

Cuando los volúmenes están identificados, protegidos y documentados, Docker puede cumplir una de sus promesas más valiosas: permitir que los contenedores sean reemplazables sin que la información importante dependa de ellos.