Cómo diseñar una política de copias de seguridad para Docker

Introducción

Diseñar una política de copias de seguridad para Docker exige proteger algo más que los contenedores. En una plataforma bien organizada, los contenedores pueden recrearse; lo realmente crítico son los datos persistentes, las bases de datos, la configuración, los secretos, las definiciones de despliegue y toda la información necesaria para reconstruir cada servicio de forma controlada.

Ese matiz cambia por completo la estrategia. Copiar indiscriminadamente el servidor, comprimir directorios mientras las aplicaciones siguen escribiendo o conservar únicamente archivos docker-compose.yml puede producir una falsa sensación de seguridad. Una copia solo es útil si contiene aquello que no puede regenerarse fácilmente, mantiene la coherencia de los datos y puede utilizarse para recuperar el servicio cuando sea necesario.

Además, no todos los proyectos Docker necesitan la misma protección. Una herramienta de laboratorio que puede reconstruirse en diez minutos no debe tratarse igual que una base de datos con información operativa. La política debe relacionar criticidad, frecuencia de cambio, pérdida de datos tolerable, tiempo de recuperación, retención, ubicación de las copias y pruebas de restauración.

Este artículo explica cómo construir esa política de forma práctica y mantenible. El objetivo no es enseñar a gestionar volúmenes desde cero ni desarrollar un procedimiento completo de recuperación ante desastre, sino establecer qué debe copiarse, con qué método, con qué frecuencia, durante cuánto tiempo, dónde debe conservarse y cómo comprobar que la copia sirve de verdad.

Índice

• Qué debe conseguir una política de copias para Docker
• Por qué el contenedor no es la unidad principal de backup
• Empezar por un inventario de datos y dependencias
• Clasificar qué debe protegerse
• Definir criticidad, RPO y RTO
• Elegir el método de copia adecuado para cada dato
• Copias consistentes de bases de datos
• Volúmenes y bind mounts dentro de la política
• Configuración, Compose y archivos de proyecto
• Secretos, claves y credenciales
• Qué hacer con imágenes Docker propias y de terceros
• Qué conviene conservar del host Docker
• Definir frecuencias de copia
• Diseñar una retención útil
• Aplicar la estrategia 3-2-1 a Docker
• Cifrado y protección de las copias
• Automatizar sin perder control
• Verificar que las copias son válidas
• Probar restauraciones sin convertirlas en un trámite
• Integrar backup y actualizaciones de contenedores
• Documentar la política
• Matriz práctica de protección
• Procedimiento de diseño paso a paso
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Qué debe conseguir una política de copias para Docker

Una política de backup no es una lista de comandos ni una tarea programada que genera archivos cada noche. Es un conjunto de decisiones que define qué información necesita protección y qué condiciones deben cumplirse para considerar que esa protección es suficiente.

En Docker, una política útil debería responder como mínimo a estas preguntas:

• ¿Qué datos no pueden reconstruirse?
• ¿Qué servicios generan información nueva?
• ¿Qué componentes pueden volver a descargarse o recrearse?
• ¿Qué bases de datos necesitan una copia coherente a nivel de aplicación?
• ¿Cuántas horas o minutos de datos sería aceptable perder?
• ¿Cuánto tiempo puede permanecer detenido cada servicio?
• ¿Cuántas versiones históricas deben conservarse?
• ¿Dónde se almacenarán las copias?
• ¿Qué copia sobreviviría a la pérdida completa del host?
• ¿Cómo se protegen las credenciales incluidas en el proceso?
• ¿Quién recibe una alerta si una tarea falla?
• ¿Cuándo se probó por última vez una restauración?

La política debe ser proporcional. Un servidor con tres servicios internos no necesita una plataforma corporativa de backup con decenas de componentes, pero sí necesita conocer sus datos, conservar copias independientes y demostrar que puede recuperarlos.

La dificultad real aparece cuando Docker hace que las aplicaciones parezcan desechables. Los contenedores sí pueden serlo; los datos que utilizan, no necesariamente. Por eso la política debe diseñarse alrededor de la persistencia y la reconstrucción, no alrededor del número de contenedores en ejecución.

Por qué el contenedor no es la unidad principal de backup

Un contenedor es una instancia creada a partir de una imagen y una configuración determinada. Si el proyecto está bien organizado, debería ser posible eliminarlo y volver a crearlo sin perder información importante.

Esto significa que guardar una copia del contenedor en sí mismo rara vez resuelve el problema principal. Lo que debe protegerse está normalmente distribuido en varias piezas:

• datos persistentes almacenados en volúmenes;
• directorios del host montados mediante bind mounts;
• bases de datos;
• archivos de configuración;
• definiciones de Docker Compose;
• variables necesarias para desplegar el proyecto;
• secretos y certificados;
• código o personalizaciones propias;
• documentación necesaria para reconstruir el servicio.

El artículo sobre qué es un contenedor explica la diferencia entre imagen, contenedor y persistencia. Para una política de backup, esa distinción es esencial: lo recreable se documenta; lo irremplazable se copia.

El problema de copiar todo sin distinguir

Una estrategia basada en copiar todo el árbol de Docker puede parecer sencilla, pero mezcla información con ciclos de vida muy diferentes: capas de imágenes descargables, cachés, metadatos internos, registros temporales y datos realmente valiosos.

Además de consumir más espacio, esa copia puede ser difícil de transportar entre versiones, hosts o configuraciones distintas. La reconstrucción resulta más limpia cuando el proyecto conserva sus definiciones y los datos persistentes se protegen por separado con métodos adecuados.

Recrear no significa improvisar

Que un contenedor sea recreable no significa que podamos confiar en la memoria. La imagen utilizada, sus versiones, el archivo Compose, los puertos, las redes, los montajes y las variables deben quedar registrados. Una plataforma es recuperable cuando puede reconstruirse de forma repetible, no cuando alguien recuerda aproximadamente cómo estaba montada.

Empezar por un inventario de datos y dependencias

No se puede diseñar una política de copias fiable sin saber qué existe. Antes de elegir herramientas o programar tareas conviene inventariar cada proyecto Docker y localizar exactamente dónde reside su estado.

Una ficha mínima por proyecto puede contener:

Si la infraestructura ya contiene muchos proyectos, conviene apoyarse en una organización coherente. El artículo sobre cómo organizar correctamente los proyectos Docker ayuda a separar archivos de despliegue, configuración y datos persistentes, algo que simplifica mucho cualquier sistema de backup.

Buscar estado oculto

Uno de los riesgos más peligrosos son los datos que nadie sabía que eran persistentes. Una aplicación puede guardar información en una ruta interna que no está montada en un volumen, generar archivos en una carpeta inesperada o depender de una base de datos externa que no aparece claramente en el proyecto.

Antes de aprobar la política hay que responder: si este contenedor desapareciera ahora, ¿qué información no volvería al recrearlo? Cualquier respuesta inesperada revela una dependencia que debe documentarse o corregirse.

Incluir dependencias compartidas

Un proyecto puede depender de un proxy inverso común, una base de datos compartida, almacenamiento externo, certificados o un sistema de autenticación. La copia de una aplicación aislada no sirve de mucho si faltan los elementos que necesita para arrancar.

La documentación general de estas relaciones puede apoyarse en cómo documentar una infraestructura basada en Docker.

Clasificar qué debe protegerse

Después del inventario conviene clasificar los activos según su capacidad de regeneración. Esta clasificación evita tratar todos los archivos con la misma prioridad.

Datos irremplazables

Son la prioridad máxima. Incluyen información creada por usuarios, registros operativos, documentos, bases de datos, configuraciones específicas o cualquier contenido que no pueda volver a obtenerse desde otra fuente fiable.

Ejemplos:

• base de datos de una aplicación;
• archivos subidos por usuarios;
• documentos generados dentro del servicio;
• históricos que solo existen en el sistema;
• personalizaciones realizadas desde la propia aplicación.

Configuración reconstruible, pero costosa

Puede volver a crearse manualmente, pero hacerlo consume tiempo y aumenta el riesgo de errores. Debe conservarse porque simplifica la recuperación.

Ejemplos:

• archivos Compose;
• configuración del proxy;
• plantillas propias;
• scripts de despliegue;
• archivos de configuración de servicios;
• mapeos de puertos y redes documentados.

Elementos regenerables

Son componentes que pueden descargarse o construirse de nuevo a partir de una fuente controlada. No siempre necesitan entrar en cada copia.

Ejemplos:

• imágenes públicas disponibles en un registro fiable;
• capas de imagen en caché;
• contenedores detenidos que no contienen datos únicos;
• archivos temporales;
• cachés que pueden regenerarse.

Información crítica de reconstrucción

Existe una categoría especial: quizá no sea un dato de negocio, pero sin ella la recuperación puede bloquearse. Aquí entran certificados, claves, secretos, versiones, nombres DNS, instrucciones de restauración y credenciales de acceso a repositorios o servicios externos.

Definir criticidad, RPO y RTO

Una política de backup no puede fijar una frecuencia razonable sin saber cuánto dato puede perderse y cuánto tiempo puede estar detenido el servicio. Dos conceptos ayudan a convertir necesidades vagas en decisiones concretas.

RPO: cuánto dato se puede perder

El RPO, objetivo de punto de recuperación, expresa la antigüedad máxima aceptable de los datos recuperados.

Si una aplicación puede perder como máximo una hora de actividad, una única copia nocturna no cumple ese objetivo. Si un repositorio documental apenas cambia una vez por semana, hacer una copia completa cada quince minutos probablemente sea innecesario.

RTO: cuánto puede durar la recuperación

El RTO, objetivo de tiempo de recuperación, expresa cuánto tiempo puede permanecer indisponible el servicio antes de que el impacto sea inaceptable.

Un RTO corto no se consigue únicamente haciendo copias frecuentes. También requiere que la copia sea accesible, que el procedimiento esté documentado, que existan recursos para restaurar y que las dependencias necesarias estén disponibles.

Clasificación sencilla

La clasificación debe hacerse por datos y servicio, no por tecnología. Una pequeña base de datos puede ser más crítica que un contenedor que consume mucha CPU.

Elegir el método de copia adecuado para cada dato

No existe un único método correcto para todos los datos de Docker. La política debe asignar un procedimiento según el tipo de información y el comportamiento de la aplicación.

Copia a nivel de aplicación

Es la opción preferible cuando la propia aplicación ofrece mecanismos de exportación o backup coherentes. Una base de datos, por ejemplo, puede generar una exportación lógica que conoce su estructura interna y evita inconsistencias propias de una simple copia de archivos.

Copia de archivos con servicio detenido

Para aplicaciones sencillas, detener temporalmente el servicio y copiar sus datos persistentes puede proporcionar una copia consistente. La desventaja es la interrupción, por lo que debe evaluarse según el RTO y la frecuencia necesaria.

Snapshot del almacenamiento

Cuando el sistema de archivos o la plataforma de almacenamiento dispone de snapshots, estos pueden reducir el tiempo durante el cual una aplicación necesita quedar congelada o detenida. Sin embargo, un snapshot del almacenamiento no garantiza por sí solo coherencia lógica de una base de datos si se toma mientras existen operaciones pendientes.

Copia de archivos en caliente

Puede ser válida para archivos que no se modifican o para aplicaciones diseñadas para ello, pero no debe suponerse que cualquier directorio puede copiarse mientras está en uso. El riesgo es obtener un conjunto de archivos perteneciente a instantes diferentes.

Combinación de métodos

En muchos proyectos la estrategia correcta es combinada:

• exportación lógica de la base de datos;
• copia de archivos subidos;
• copia de configuración;
• conservación del Compose y scripts;
• custodia independiente de secretos;
• registro de versiones de imágenes.

La política debe describir esa combinación como una unidad de recuperación. Tener cinco copias independientes no sirve si no sabemos qué versiones pertenecen al mismo punto temporal.

Copias consistentes de bases de datos

Las bases de datos son uno de los puntos donde más fácilmente una copia aparentemente correcta puede resultar inutilizable. Copiar los archivos internos de una base de datos mientras está escribiendo puede producir un estado incoherente, aunque la herramienta de copia termine sin mostrar errores.

Preferir herramientas propias de la base de datos

Cuando sea posible, conviene utilizar los mecanismos soportados por el motor: exportaciones lógicas, herramientas de backup físico diseñadas para ejecución en caliente o procedimientos específicos del producto.

El principio es sencillo: la aplicación que entiende el formato de los datos suele estar mejor preparada para producir una copia coherente que una herramienta genérica de archivos.

Relacionar dump y archivos asociados

Algunas aplicaciones guardan parte del estado en base de datos y otra parte en el sistema de archivos. Por ejemplo, la base puede contener metadatos mientras los documentos reales se almacenan en un volumen.

La política debe decidir cómo obtener un punto coherente entre ambas piezas. Dependiendo de la aplicación puede ser necesario:

• detener escrituras durante la copia;
• usar un modo de mantenimiento;
• generar el dump y copiar los archivos inmediatamente después;
• usar snapshots coordinados;
• seguir el procedimiento de backup recomendado por la aplicación.

Comprobar que la exportación termina correctamente

Generar un archivo no significa que el dump sea válido. La tarea debe verificar el código de salida, el tamaño razonable del archivo y, cuando sea posible, realizar comprobaciones adicionales.

No confundir replicación y backup

Una réplica puede mejorar disponibilidad, pero normalmente reproduce también borrados, corrupción lógica o cambios no deseados. La política necesita copias con histórico independiente aunque exista replicación.

Volúmenes y bind mounts dentro de la política

Docker puede persistir datos mediante volúmenes gestionados o mediante directorios del host montados en el contenedor. La política debe saber cuál utiliza cada servicio, dónde se encuentra la información y qué método es apropiado para protegerla.

La gestión operativa completa de estos elementos se desarrolla en cómo gestionar correctamente los volúmenes Docker. Desde el punto de vista del backup, interesan especialmente cuatro cuestiones.

Identificación

Cada volumen debe poder asociarse a un proyecto, servicio y tipo de dato. Un volumen con un nombre genérico que nadie puede relacionar con una aplicación aumenta el riesgo de dejar información fuera del backup o borrar algo necesario.

Consistencia

Antes de copiar hay que conocer si el contenido cambia mientras la aplicación está activa. Para bases de datos o aplicaciones con escrituras continuas, una copia de archivos en caliente puede no ser suficiente.

Granularidad

No todos los volúmenes necesitan la misma frecuencia. Un volumen de documentos de usuario puede cambiar continuamente, mientras una carpeta de configuración apenas cambia tras una actualización.

Restaurabilidad

La copia debe poder devolver los datos a una ubicación conocida con propietarios y permisos adecuados. La restauración no termina cuando los archivos existen: el contenedor debe poder utilizarlos correctamente.

No basar la política en rutas internas opacas

Es preferible diseñar el proyecto para que la persistencia sea explícita y esté documentada. Depender de encontrar después archivos dentro de estructuras internas del motor dificulta migraciones y recuperaciones.

Configuración, Compose y archivos de proyecto

Los datos son esenciales, pero una recuperación rápida también necesita reconstruir correctamente el servicio. Por eso los archivos que definen el despliegue forman parte de la política.

Conviene conservar:

• archivos compose.yaml o equivalentes;
• Dockerfiles propios;
• configuraciones del proxy;
• scripts de inicialización;
• plantillas de configuración;
• archivos auxiliares necesarios para construir imágenes;
• documentación de versiones;
• procedimientos de despliegue.

Control de versiones cuando sea posible

Los archivos no secretos deberían mantenerse en un sistema de control de versiones. Esto aporta histórico, trazabilidad y capacidad para reconstruir una configuración anterior sin depender únicamente del sistema de backup.

El control de versiones y el backup se complementan. Git puede conservar cambios de configuración, pero no sustituye las copias de bases de datos, archivos de usuarios o secretos.

Guardar la configuración que realmente está desplegada

Un repositorio puede contener una definición teórica mientras producción tiene modificaciones manuales. Esa divergencia es peligrosa. La política debe acompañarse de una disciplina de despliegue que evite cambios invisibles.

Evitar configuraciones únicas dentro del contenedor

Si una modificación importante se realiza manualmente dentro de un contenedor y no queda reflejada en imagen, configuración o volumen, desaparecerá al recrearlo. Ese tipo de cambio debe considerarse un defecto de mantenibilidad, no algo que el backup tenga que perseguir.

Secretos, claves y credenciales

Una plataforma puede tener copias perfectas de sus datos y seguir siendo irrecuperable si pierde las claves necesarias para descifrar, autenticar o acceder a servicios externos.

La política debe contemplar:

• contraseñas de bases de datos;
• tokens de APIs;
• claves privadas;
• certificados;
• credenciales de registros privados;
• claves de cifrado;
• credenciales utilizadas por sistemas de backup.

No mezclar secretos con copias sin protección

Incluir un archivo con todas las contraseñas dentro de un backup sin cifrar puede convertir la copia en un objetivo más peligroso que el propio servidor. Los secretos deben custodiarse mediante un mecanismo adecuado y con acceso restringido.

Evitar una dependencia circular

La clave necesaria para descifrar las copias no debe existir únicamente dentro del servidor que estamos intentando recuperar. Debe haber una forma segura de obtenerla cuando ese host ya no esté disponible.

Documentar existencia, no exponer contenido

La documentación de la plataforma debe indicar qué secretos necesita cada proyecto y dónde se custodian, pero no tiene por qué incluir el secreto en texto claro. Esta separación facilita auditoría sin aumentar exposición.

Qué hacer con imágenes Docker propias y de terceros

No todas las imágenes necesitan copiarse como parte del backup diario. Una imagen pública, fijada a una versión conocida y disponible en un registro fiable, puede volver a descargarse.

Sin embargo, la política debe diferenciar varios escenarios.

Imágenes públicas reproducibles

Conviene registrar repositorio, etiqueta o identificador de versión utilizado. Si el proyecto puede reconstruirse con esa referencia, no es necesario duplicar cada capa en el sistema de copias.

Imágenes propias construibles

Si la organización conserva Dockerfile, código, dependencias y procedimiento de construcción, la imagen puede regenerarse. Aun así, puede ser útil conservarla en un registro propio para acelerar recuperación.

Imágenes propias no reproducibles

Si existe una imagen que contiene modificaciones que no están documentadas ni versionadas, la prioridad debería ser corregir esa situación. Mientras tanto, esa imagen constituye un activo único y debe protegerse.

Imágenes de terceros que podrían desaparecer

Cuando un servicio depende de una imagen antigua, poco mantenida o difícil de obtener, conviene evaluar si mantener una copia en un registro controlado. La política debe anticipar la desaparición de una fuente externa.

Para ordenar este aspecto sin mezclarlo con la estrategia de backup puede consultarse cómo organizar imágenes Docker propias y de terceros.

Qué conviene conservar del host Docker

El objetivo de una política mantenible no debería ser depender de una imagen exacta e irrepetible del servidor. Cuanto más reproducible sea el host, más sencilla será la recuperación.

Conviene conservar o documentar:

• sistema operativo y versión utilizada;
• versión y método de instalación de Docker;
• configuración relevante del daemon;
• reglas de firewall relacionadas con los servicios;
• configuración del proxy o balanceador cuando esté en el host;
• tareas programadas de backup;
• rutas de proyectos y datos;
• usuarios y permisos técnicos necesarios;
• montajes de almacenamiento externo;
• procedimiento para preparar un host nuevo.

No confiar únicamente en copiar el directorio interno de Docker

Copiar de forma indiscriminada el directorio de datos del motor no debería ser la estrategia principal de recuperación. Contiene estado interno, capas, metadatos y datos cuyo uso puede depender de versión, almacenamiento y estado del daemon.

Es más robusto proteger explícitamente los datos persistentes y conservar definiciones reproducibles de la plataforma. Si además se realiza una copia de sistema completa como capa adicional, debe considerarse un complemento, no la única defensa.

El host también necesita su propia política

Docker no sustituye las copias del sistema Linux. Configuraciones fuera de los proyectos, certificados, scripts y otros servicios del host deben entrar en la estrategia general del servidor cuando sean necesarios para recuperarlo.

Definir frecuencias de copia

La frecuencia debe derivarse del RPO y de la velocidad con la que cambian los datos. Hacer una copia diaria por costumbre puede ser demasiado poco para un servicio activo y excesivo para un archivo casi estático.

Ejemplo de frecuencias diferenciadas

Estas frecuencias son ejemplos de diseño, no valores universales. La frecuencia real debe ajustarse a la pérdida tolerable, volumen, coste y capacidad de restauración.

Copiar después de cambios relevantes

Además de las tareas periódicas, puede ser prudente generar una copia antes o después de determinadas intervenciones:

• actualizaciones con migración de datos;
• cambios de configuración importantes;
• modificaciones de esquema;
• migraciones entre hosts;
• reorganización del almacenamiento;
• retirada de una versión antigua.

Diseñar una retención útil

Conservar únicamente la última copia es arriesgado. Un error puede permanecer oculto durante días y aparecer cuando todas las copias recientes ya contienen el problema.

La retención debe ofrecer profundidad temporal suficiente para recuperar estados anteriores sin conservar indefinidamente todo lo generado.

Modelo por niveles

Un esquema habitual puede combinar:

• copias frecuentes de las últimas horas o días;
• copias diarias durante varias semanas;
• copias semanales durante varios meses;
• copias mensuales cuando exista una necesidad histórica o regulatoria.

La duración concreta depende de la aplicación. Lo importante es evitar una política donde todas las versiones antiguas desaparecen antes de que sea razonable detectar una corrupción o eliminación.

Retención no es archivo histórico

El sistema de backup sirve para recuperación. Un requisito de conservación documental durante años puede necesitar un sistema de archivo diferente, con sus propias reglas de integridad, acceso y eliminación.

Controlar crecimiento

Las copias de volúmenes grandes, bases de datos y archivos multimedia pueden crecer con rapidez. Conviene estimar capacidad, deduplicación o compresión disponible y revisar periódicamente que la retención definida sigue siendo sostenible.

Aplicar la estrategia 3-2-1 a Docker

La conocida regla 3-2-1 sigue siendo útil como principio general: mantener varias copias, utilizar más de un tipo o ámbito de almacenamiento y conservar al menos una copia fuera del sistema principal.

En Docker podría traducirse, por ejemplo, en:

1. Datos de producción en el almacenamiento utilizado por el host.
2. Copia local independiente en otro dispositivo, repositorio o sistema de backup.
3. Copia externa fuera del servidor y, preferiblemente, fuera de la misma ubicación física.

La estrategia general se desarrolla en cómo implementar copias 3-2-1. En Docker, la clave consiste en aplicarla a los activos correctos: datos, configuraciones y elementos de reconstrucción.

Una copia en otro volumen del mismo host no es suficiente

Si un fallo de disco, ransomware, error administrativo o avería del servidor afecta a ambos conjuntos, la duplicación local no proporciona independencia real.

Separación lógica y física

Cuanto más crítico sea el servicio, más importante resulta que una de las copias esté protegida frente a las mismas credenciales, errores y fallos que afectan a producción.

Copia externa accesible, pero no demasiado expuesta

Una copia remota debe poder recuperarse cuando haga falta, pero no debería quedar permanentemente accesible con permisos de borrado desde cualquier proceso comprometido del host. El diseño debe equilibrar automatización y aislamiento.

Cifrado y protección de las copias

Los backups suelen contener una concentración de información sensible: bases de datos completas, documentos, configuraciones, tokens, certificados o históricos que normalmente están repartidos entre varios servicios.

Cifrar durante la transferencia

Las copias enviadas a otro servidor o almacenamiento deben viajar mediante protocolos protegidos. El tráfico de backup no debería exponer datos o credenciales en redes no confiables.

Cifrar en reposo cuando sea necesario

Si el destino está fuera del control físico directo o contiene información sensible, el cifrado en reposo reduce el impacto de una pérdida o acceso no autorizado.

Proteger la clave de recuperación

El cifrado aporta seguridad solo si la clave está bien custodiada y disponible durante una emergencia. Perder la clave convierte una copia correcta en datos inutilizables.

Aplicar mínimo privilegio

La cuenta utilizada para enviar copias no necesita necesariamente capacidad para administrar todo el repositorio. Separar permisos puede impedir que un compromiso del host elimine todas las generaciones históricas.

Registrar accesos administrativos

Para copias críticas conviene disponer de trazabilidad sobre borrados, cambios de retención y modificaciones de credenciales. Un backup también es infraestructura que debe administrarse.

Automatizar sin perder control

Una política que depende de recordar tareas manuales terminará fallando. La automatización es necesaria, pero debe incluir controles que permitan saber si realmente está funcionando.

Una tarea automática debería informar de:

• hora de inicio y fin;
• proyecto o activo copiado;
• resultado;
• cantidad de datos transferidos;
• errores o elementos omitidos;
• destino utilizado;
• retención aplicada.

El silencio no significa éxito

Un cron que deja de ejecutarse puede pasar semanas sin que nadie lo note. La supervisión debe detectar tanto los fallos explícitos como la ausencia de una copia esperada.

No automatizar un proceso que todavía no está entendido

Primero hay que definir qué datos se copian, cómo se obtiene consistencia y cómo se restaura. Después puede automatizarse. Automatizar una copia mal diseñada solo produce errores de forma más puntual.

Evitar credenciales incrustadas en scripts

Los scripts no deberían contener contraseñas en texto claro por comodidad. Conviene utilizar mecanismos de credenciales con permisos limitados y proteger el entorno donde se ejecutan.

Verificar que las copias son válidas

La existencia de un archivo no demuestra que una copia sea recuperable. La política debe incluir comprobaciones automáticas y revisiones periódicas.

Comprobaciones básicas

• la tarea terminó sin errores;
• el archivo o conjunto generado existe;
• el tamaño está dentro de un rango razonable;
• el destino dispone de espacio;
• la copia reciente aparece en el repositorio;
• la retención elimina solo lo previsto;
• la suma de verificación o mecanismo de integridad es correcta cuando se utiliza;
• el repositorio puede leerse con las credenciales de recuperación.

Detectar copias sospechosamente pequeñas

Una base de datos que normalmente genera varios gigabytes y de repente produce unos pocos kilobytes merece una alerta aunque el proceso haya terminado con código de éxito.

Vigilar la edad de la última copia válida

Este indicador es especialmente útil porque conecta directamente con el RPO. Si la última copia válida supera la antigüedad tolerable, el servicio está fuera de política.

La lógica de validación puede complementarse con cómo verificar que una copia de seguridad de un servidor Linux realmente funciona, aplicando esas comprobaciones al contexto específico de Docker.

Probar restauraciones sin convertirlas en un trámite

Una política de backup termina en la restauración. Si nunca se intenta recuperar una copia, solo se conoce el proceso de escritura, no el de recuperación.

Qué debe probarse

Una prueba útil debería demostrar que:

• los datos pueden extraerse del repositorio;
• las claves necesarias están disponibles;
• la base de datos acepta la restauración;
• los archivos recuperados mantienen contenido y permisos adecuados;
• la aplicación puede arrancar con los datos restaurados;
• las funciones principales responden;
• el procedimiento puede ejecutarse con la documentación existente.

Restaurar en un entorno aislado

Cuando sea posible, conviene probar en un host, máquina virtual, proyecto o espacio separado. Así se evita sobrescribir producción mientras se valida la copia.

Variar las pruebas

No siempre debe restaurarse el mismo pequeño archivo. A lo largo del tiempo interesa probar distintas capas: una base de datos, un volumen, un proyecto completo o una copia externa.

Registrar duración y problemas

La prueba también sirve para comprobar el RTO. Si recuperar un servicio tarda ocho horas cuando la política exige dos, el problema debe corregirse aunque la copia sea técnicamente válida.

El procedimiento exhaustivo para reconstruir una plataforma después de un fallo grave merece un tratamiento específico. Aquí basta con establecer que las pruebas de restauración forman parte obligatoria de la política de backup.

Integrar backup y actualizaciones de contenedores

Las actualizaciones son uno de los momentos donde una copia reciente aporta más valor. Una nueva versión puede modificar esquemas, formatos de configuración o datos persistentes.

La política debería definir cuándo una actualización exige una copia previa. Por ejemplo:

• antes de una migración de base de datos;
• antes de cambiar una versión principal;
• antes de modificar estructura de volúmenes;
• antes de ejecutar scripts de migración;
• antes de retirar definitivamente la versión anterior.

Esto no significa generar backups completos antes de cualquier recreación trivial. Debe aplicarse según el riesgo del cambio.

La planificación de versiones, pruebas y rollback se desarrolla en cómo diseñar una estrategia de actualización de contenedores Docker. La política de copias aporta la capa de protección de datos que esa estrategia necesita.

Comprobar que el backup es anterior a la migración

En una actualización con cambios irreversibles de esquema, no basta con saber que existe “una copia de hoy”. Conviene identificar claramente qué backup corresponde al estado anterior al cambio.

No asumir que volver a la imagen anterior restaura los datos

Un rollback de contenedor puede fallar si la nueva versión ya modificó la base de datos. Por eso las copias y las actualizaciones deben diseñarse de forma coordinada.

Documentar la política

Una política efectiva debe poder entenderla una persona autorizada que no haya diseñado originalmente la plataforma. La documentación no necesita ser extensa, pero sí operativa.

Ficha mínima por servicio

• nombre del proyecto;
• responsable;
• nivel de criticidad;
• datos que deben copiarse;
• método de copia;
• frecuencia;
• RPO y RTO;
• destinos;
• retención;
• cifrado aplicado;
• alertas configuradas;
• procedimiento de restauración;
• fecha de última prueba;
• resultado de la prueba.

Documentar excepciones

Si un servicio no tiene copia porque puede reconstruirse completamente, esa decisión también debe quedar registrada. Así se evita que alguien interprete una ausencia accidental como una elección consciente.

Actualizar la documentación al cambiar la plataforma

Crear un nuevo volumen, mover una base de datos, cambiar el repositorio de backup o rotar una clave puede invalidar el procedimiento. La documentación debe formar parte del cambio, no una tarea pendiente para después.

Una estructura documental más amplia puede consultarse en cómo documentar una infraestructura basada en Docker.

Matriz práctica de protección

Una matriz ayuda a visualizar la política y detectar activos sin protección.

La matriz real puede añadir columnas de destino, cifrado, propietario, tamaño, retención y última prueba. El objetivo es hacer visible cualquier hueco.

Procedimiento de diseño paso a paso

Paso 1. Inventariar proyectos

Crear una lista de aplicaciones, servicios, volúmenes, bases de datos, bind mounts, configuraciones y dependencias.

Paso 2. Localizar el estado persistente

Identificar exactamente qué información sobreviviría o se perdería al eliminar cada contenedor.

Paso 3. Separar lo regenerable de lo irremplazable

No utilizar el mismo esfuerzo para imágenes descargables y datos únicos.

Paso 4. Clasificar criticidad

Determinar el impacto de pérdida e interrupción para cada servicio.

Paso 5. Definir RPO y RTO

Convertir la criticidad en límites concretos de pérdida de datos y tiempo de recuperación.

Paso 6. Elegir método de copia

Usar backups nativos para bases de datos, copias de archivos donde sean coherentes y snapshots cuando aporten valor.

Paso 7. Diseñar destinos

Evitar que todas las copias dependan del mismo host, almacenamiento o credenciales.

Paso 8. Definir frecuencia y retención

Ajustar periodicidad al RPO y mantener profundidad temporal suficiente para detectar errores tardíos.

Paso 9. Proteger credenciales y copias

Aplicar cifrado, mínimo privilegio y custodia independiente de claves cuando corresponda.

Paso 10. Automatizar

Programar las tareas solo después de que el procedimiento manual esté entendido y probado.

Paso 11. Crear alertas

Detectar fallos, copias ausentes, crecimiento anormal y antigüedad excesiva de la última copia válida.

Paso 12. Probar restauraciones

Recuperar periódicamente datos y servicios en un entorno aislado, midiendo tiempos y verificando funcionamiento.

Paso 13. Documentar

Registrar responsables, métodos, ubicaciones, retención, RPO, RTO y procedimiento de recuperación.

Paso 14. Revisar después de cada cambio importante

Nuevos servicios, volúmenes, migraciones o cambios de almacenamiento deben provocar una revisión de la política.

Errores frecuentes

Copiar solo los archivos Compose

Permiten recrear contenedores, pero no recuperan bases de datos, documentos ni otros datos persistentes.

Copiar solo los volúmenes

Puede faltar configuración, secretos, imágenes propias o documentación necesaria para reconstruir el entorno.

Copiar una base de datos activa como si fueran archivos normales

Puede producir una copia incoherente. Debe utilizarse un método compatible con el motor y el estado de la aplicación.

Guardar todas las copias en el mismo servidor

Una avería, borrado, ataque o error de almacenamiento puede eliminar producción y backups simultáneamente.

Conservar únicamente la última copia

Un problema descubierto tarde puede estar ya presente en esa única versión.

No proteger los secretos

Una copia completa pero sin claves puede ser irrecuperable; una copia con claves expuestas puede ser insegura.

No comprobar el resultado de las tareas

Un backup automático que falla silenciosamente es peor que un proceso manual bien supervisado porque genera confianza injustificada.

No probar restauraciones

Hasta que no se restaura, no se conoce si faltan archivos, permisos, versiones o instrucciones.

Usar la misma frecuencia para todo

Desperdicia recursos en datos estáticos y deja insuficientemente protegidos los datos que cambian rápido.

Ignorar las dependencias

Una aplicación puede recuperar sus datos y seguir sin arrancar porque falta el proxy, un certificado, una clave o un servicio compartido.

Confundir snapshot con backup externo

Un snapshot facilita volver a un estado anterior dentro del mismo almacenamiento, pero no necesariamente protege frente a la pérdida de ese almacenamiento.

Respaldar basura indefinidamente

Cachés, temporales, imágenes regenerables y logs sin valor pueden inflar las copias y dificultar la recuperación.

No revisar la política cuando cambia el proyecto

Un volumen nuevo o una base de datos trasladada puede quedar fuera de las tareas existentes.

Lista de comprobación

Preguntas frecuentes

Conclusión

Una política de copias de seguridad para Docker debe construirse alrededor de los datos y de la capacidad de reconstrucción, no alrededor de los contenedores como objetos aislados.

El primer paso consiste en saber qué persiste: bases de datos, volúmenes, bind mounts, archivos de usuario, configuración, secretos y elementos de despliegue. Después hay que clasificar criticidad, definir RPO y RTO, elegir métodos de copia coherentes y distribuir las copias de forma que un único fallo no pueda destruirlas todas.

La política también necesita retención, cifrado cuando corresponda, automatización, alertas y documentación. Pero ninguna de esas capas sustituye la prueba fundamental: restaurar periódicamente y comprobar que el servicio puede volver a funcionar con los datos recuperados.

Docker facilita reconstruir aplicaciones cuando imágenes, configuración y persistencia están bien separados. Esa característica no reduce la importancia del backup; permite diseñarlo mejor. En vez de copiar indiscriminadamente todo el servidor, se protege aquello que realmente tiene valor y se documenta aquello que debe poder recrearse.

Una buena política consigue que la pérdida de un contenedor sea irrelevante, que la pérdida de un host sea recuperable y que la pérdida de datos permanezca dentro de límites previamente aceptados y comprobados.