Cómo restaurar una plataforma Docker tras un fallo grave

Introducción

Restaurar una plataforma Docker tras un fallo grave no consiste simplemente en volver a ejecutar unos contenedores. Cuando se pierde un servidor, se corrompe el almacenamiento, una actualización deja varios servicios inutilizables o un error administrativo destruye parte de la plataforma, el verdadero problema es reconstruir un sistema coherente: host, Docker, proyectos, redes, volúmenes, bases de datos, configuración, secretos, certificados y dependencias externas.

La aparente facilidad con la que Docker permite crear contenedores puede generar una falsa sensación de recuperación sencilla. Las imágenes pueden volver a descargarse y los contenedores pueden recrearse, pero eso no garantiza que reaparezcan los datos correctos, que las versiones coincidan, que las credenciales sigan siendo válidas ni que los servicios arranquen en el orden adecuado.

Una recuperación seria empieza antes de ejecutar comandos. Hay que determinar qué se ha perdido, qué sigue siendo confiable, cuál era el último estado válido y si conviene reparar el entorno existente o reconstruirlo sobre una base limpia. Después hay que restaurar cada capa en un orden lógico y comprobar no solo que los contenedores figuran como activos, sino que las aplicaciones funcionan de extremo a extremo.

Este artículo explica cómo abordar una recuperación completa de Docker desde una perspectiva práctica y formativa. El objetivo es aprender a responder ante fallos graves con método, reducir improvisaciones y convertir la capacidad de reconstrucción en una propiedad real de la infraestructura.

La preparación previa de las copias se desarrolla en cómo diseñar una política de copias de seguridad para Docker. Aquí partimos de una situación distinta: el fallo ya ha ocurrido y hay que recuperar el servicio.

Índice

• Qué significa un fallo grave en Docker
• El objetivo real: recuperar el servicio, no los contenedores
• Qué hacer en los primeros minutos
• Clasificar el daño antes de restaurar
• Decidir entre reparar y reconstruir
• Crear un inventario mínimo de recuperación
• Identificar las fuentes confiables
• Preparar un host limpio
• Restaurar proyectos y estructura de despliegue
• Recuperar imágenes y versiones correctas
• Reconstruir redes, puertos y entrada de tráfico
• Recuperar secretos, certificados y credenciales
• Restaurar volúmenes y datos persistentes
• Restaurar bases de datos con consistencia
• Definir el orden de recuperación
• Arrancar servicios de forma controlada
• Validar la plataforma después de restaurarla
• Qué hacer con los datos posteriores a la copia
• Recuperación cuando existe sospecha de intrusión
• Revisar dependencias externas
• Documentar la recuperación
• Convertir el incidente en mejoras concretas
• Procedimiento resumido paso a paso
• Errores frecuentes durante la recuperación
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Qué significa un fallo grave en Docker

No todo problema en Docker exige una recuperación completa. Un contenedor detenido, una imagen defectuosa o una variable mal configurada pueden solucionarse sin reconstruir la plataforma. Hablamos de fallo grave cuando la continuidad del entorno queda comprometida y ya no existe una ruta fiable para volver al estado anterior mediante una corrección sencilla.

Algunos escenarios típicos son:

• pérdida total del servidor físico o virtual;
• corrupción del sistema de archivos;
• avería del almacenamiento que contiene datos persistentes;
• eliminación accidental de varios volúmenes;
• borrado o corrupción de la estructura de proyectos;
• actualización que altera simultáneamente varias dependencias;
• migración incompleta que deja datos y configuración en estados distintos;
• compromiso de seguridad que obliga a considerar el host no confiable;
• pérdida de credenciales o certificados esenciales;
• fallo del hipervisor o de la máquina virtual que alojaba Docker;
• error administrativo que elimina recursos compartidos por varios servicios.

La gravedad no depende únicamente del número de contenedores afectados. Un único contenedor de base de datos puede ser mucho más crítico que veinte servicios auxiliares. El criterio adecuado es medir el impacto sobre los datos, las dependencias y la capacidad de reconstrucción.

La gestión correcta de los datos persistentes se desarrolla en cómo gestionar correctamente los volúmenes Docker. En una recuperación, ese conocimiento resulta decisivo porque permite distinguir qué recursos pueden recrearse y cuáles deben recuperarse desde copias verificadas.

El objetivo real: recuperar el servicio, no los contenedores

Docker hace visible una lista de contenedores, pero esa lista no representa por sí sola el sistema que los usuarios necesitan. Una aplicación real puede depender de una base de datos, un proxy inverso, almacenamiento persistente, DNS, certificados, credenciales, APIs externas y tareas programadas.

Por eso, una recuperación no debe considerarse finalizada porque este comando muestre todos los servicios como activos:

docker ps

Un contenedor puede estar en estado Up y, sin embargo:

• tener una base de datos vacía;
• estar usando una versión incorrecta;
• no alcanzar otro servicio interno;
• carecer de certificados válidos;
• responder en el puerto local pero no desde el exterior;
• tener permisos incorrectos sobre sus datos;
• fallar al enviar correo o consumir una API;
• haber perdido tareas programadas;
• mostrar información antigua o inconsistente.

La unidad de recuperación debe ser el servicio funcional completo. La pregunta no es “¿ha arrancado el contenedor?”, sino “¿puede el sistema realizar correctamente las funciones para las que existe?”.

Qué hacer en los primeros minutos

Los primeros minutos de un fallo grave son un momento peligroso porque existe presión por recuperar rápido. Esa presión puede llevar a ejecutar acciones destructivas antes de comprender qué ha ocurrido.

Detener cambios innecesarios

Si todavía existe acceso al host afectado, conviene evitar operaciones que modifiquen datos: limpiezas, recreaciones masivas, eliminación de volúmenes, actualizaciones o nuevos despliegues. Cada cambio puede borrar evidencia útil o reducir las posibilidades de recuperación.

Registrar el estado observado

Antes de modificar el entorno, anota la hora, síntomas, servicios afectados, cambios recientes y cualquier mensaje relevante. Si es posible, conserva salidas de comandos y registros.

Por ejemplo:

docker ps -a
docker volume ls
docker network ls
docker images
docker compose ls
df -h
free -h

Estos comandos no sustituyen un diagnóstico completo, pero ayudan a obtener una fotografía inicial.

No asumir inmediatamente que la copia es la solución

Restaurar demasiado pronto puede sobrescribir datos todavía recuperables. Primero hay que entender qué está dañado y qué no.

Separar diagnóstico y recuperación

El diagnóstico responde a “qué ha pasado”. La recuperación responde a “cómo devolvemos el servicio a un estado válido”. Mezclarlos sin método puede conducir a reparar una causa mientras se destruye información necesaria para restaurar.

Clasificar el daño antes de restaurar

Una forma útil de abordar el incidente es dividir la plataforma por capas y clasificar cada una como intacta, dudosa o perdida.

Esta clasificación evita el enfoque de “restaurarlo todo” cuando solo una capa está dañada, y también evita confiar en componentes que han quedado en un estado dudoso.

Decidir entre reparar y reconstruir

Una de las decisiones más importantes consiste en determinar si merece la pena reparar el host existente o reconstruir la plataforma sobre un sistema limpio.

Reparar puede tener sentido cuando

• el sistema operativo y el almacenamiento son confiables;
• el problema está localizado;
• se conoce la causa;
• los datos persistentes están intactos;
• no existe sospecha de intrusión;
• la reparación puede probarse y revertirse.

Reconstruir suele ser preferible cuando

• el host presenta corrupción difícil de delimitar;
• se desconoce qué cambios se han producido;
• el almacenamiento ha fallado físicamente;
• existe sospecha de compromiso de seguridad;
• Docker y sus metadatos internos están dañados;
• la configuración manual acumulada impide saber qué es válido;
• una reconstrucción limpia es más previsible que una cadena de reparaciones.

Docker aporta una ventaja importante: si los proyectos están bien documentados, las imágenes son reproducibles y los datos permanecen separados, el host puede tratarse como una capa reemplazable. Esa propiedad reduce la tentación de mantener vivo un sistema cuyo estado ya no inspira confianza.

El diseño de una plataforma con capas claras se relaciona con cómo diseñar una plataforma Docker para una pequeña empresa.

Crear un inventario mínimo de recuperación

Antes de reconstruir, conviene preparar una tabla de los servicios que deben recuperarse. No hace falta comenzar con documentación perfecta: basta con un inventario operativo que permita ordenar el trabajo.

Para cada servicio anota:

• nombre del proyecto;
• función;
• criticidad;
• archivo de despliegue;
• imágenes y versiones;
• volúmenes o bind mounts;
• base de datos asociada;
• redes utilizadas;
• puertos publicados;
• dominio o URL;
• secretos necesarios;
• dependencias de otros proyectos;
• dependencias externas;
• última copia disponible;
• forma de validar que funciona.

Si esta información ya estaba documentada, la recuperación será considerablemente más rápida. Si hay que reconstruirla durante la incidencia, conviene conservarla después. El artículo cómo documentar una infraestructura basada en Docker desarrolla precisamente esa disciplina.

Identificar las fuentes confiables

Durante una recuperación suelen aparecer varias copias de lo mismo: archivos Compose locales, repositorios, backups, imágenes presentes en el host, configuraciones antiguas y notas. El riesgo consiste en mezclar versiones de momentos diferentes.

Conviene definir una fuente confiable para cada tipo de elemento:

La regla es sencilla: no reconstruyas una plataforma mezclando piezas cuya procedencia no puedes explicar. Una recuperación que funciona hoy pero no puede reproducirse mañana deja una nueva deuda técnica.

Preparar un host limpio

Si se ha decidido reconstruir, el nuevo host debe ser deliberadamente sencillo. No conviene aprovechar la emergencia para rediseñar toda la infraestructura, cambiar simultáneamente de distribución, alterar rutas, actualizar todas las aplicaciones y reorganizar redes.

Objetivo del host de recuperación

El objetivo es recrear un entorno suficientemente compatible para devolver los servicios a funcionamiento con el menor número posible de variables nuevas.

Conviene verificar:

• versión del sistema operativo;
• arquitectura de CPU;
• capacidad de RAM y almacenamiento;
• puntos de montaje;
• Docker Engine;
• plugin Docker Compose;
• firewall;
• sincronización horaria;
• DNS;
• rutas de proyectos;
• permisos de archivos;
• espacio temporal para restauraciones.

No copies ciegamente el directorio interno de Docker

Copiar de forma indiscriminada directorios internos del motor desde un sistema dañado puede trasladar también inconsistencias. Cuando la arquitectura lo permite, suele ser más limpio reinstalar Docker, recrear redes y contenedores desde sus definiciones y restaurar únicamente los datos que realmente deben persistir.

El principio de separar aplicaciones, datos y configuración puede ampliarse en cómo separar correctamente aplicaciones, datos y configuración.

Restaurar proyectos y estructura de despliegue

Antes de recuperar datos conviene reconstruir la estructura lógica de los proyectos. Esto permite comprobar rutas, nombres, archivos de configuración y dependencias sin arrancar todavía aplicaciones que puedan modificar los datos restaurados.

Una estructura ordenada podría ser:

/srv/docker/
├── proxy/
├── aplicacion-a/
├── aplicacion-b/
├── monitorizacion/
└── automatizacion/

Dentro de cada proyecto deben recuperarse los elementos que definían el despliegue:

• compose.yaml o docker-compose.yml;
• Dockerfile cuando exista;
• archivos de configuración;
• plantillas;
• scripts auxiliares;
• variables no secretas;
• documentación del proyecto.

El artículo cómo organizar correctamente los proyectos Docker explica cómo mantener estas piezas de forma previsible. Esa organización demuestra su valor precisamente cuando el host original deja de estar disponible.

Validar antes de arrancar

Docker Compose permite comprobar la configuración resultante y detectar variables ausentes o errores de sintaxis antes de crear contenedores.

docker compose config

La salida debe revisarse con cuidado para evitar exponer secretos en registros o capturas.

Recuperar imágenes y versiones correctas

Una restauración puede fallar aunque los datos sean correctos si se ejecutan imágenes distintas de las que existían cuando se generó la copia.

Evitar etiquetas ambiguas

Una definición como:

image: aplicacion:latest

no garantiza que hoy descargues el mismo software que funcionaba antes del incidente. Para servicios importantes conviene trabajar con versiones identificadas y, cuando la criticidad lo justifique, con referencias aún más precisas.

Imágenes propias

Si la plataforma utilizaba imágenes construidas internamente, debe existir una fuente reproducible: código, Dockerfile, dependencias y procedimiento de construcción. Conservar únicamente una imagen local en el host fallido es una dependencia peligrosa.

Imágenes de terceros

Comprueba que la versión necesaria sigue disponible y procede de una fuente confiable. No es buen momento para sustituirla por una versión mayor “ya que estamos”. Primero recupera; después podrás planificar una actualización independiente.

La organización de estas dependencias se desarrolla en cómo organizar imágenes Docker propias y de terceros.

Reconstruir redes, puertos y entrada de tráfico

Las redes Docker pueden recrearse, pero su diseño debe respetar las relaciones entre servicios. Una aplicación puede arrancar correctamente y seguir sin funcionar porque no alcanza su base de datos, el proxy no resuelve su nombre interno o se ha publicado un puerto distinto.

Redes internas

Comprueba qué proyectos utilizaban redes propias y cuáles compartían una red común, por ejemplo con un proxy inverso. No conectes todos los contenedores a todas las redes “para que funcione”. Esa solución elimina aislamiento y oculta el diseño real.

Puertos

Verifica puertos internos y externos. Un servicio restaurado en otro puerto puede romper firewall, monitorización, scripts o integraciones.

Proxy inverso

Si existe un proxy común, suele ser una dependencia prioritaria. Puede requerir:

• red compartida;
• configuración de hosts;
• certificados;
• resolución DNS;
• acceso a archivos de configuración;
• puertos 80 y 443 disponibles.

DNS

Si la dirección IP del host cambia durante la recuperación, habrá que revisar registros DNS, TTL, reglas de firewall y posibles listas blancas externas.

Recuperar secretos, certificados y credenciales

Los archivos de proyecto pueden estar perfectamente conservados y, aun así, la plataforma no arrancar porque faltan credenciales.

Entre los elementos críticos pueden aparecer:

• contraseñas de bases de datos;
• tokens de API;
• claves privadas;
• credenciales SMTP;
• secretos de sesión;
• claves de cifrado;
• certificados TLS;
• credenciales de registros privados;
• usuarios técnicos;
• claves SSH utilizadas por automatizaciones.

No improvisar valores nuevos sin analizar consecuencias

Cambiar una contraseña puede parecer sencillo, pero quizá otra aplicación dependa de ella. Cambiar una clave de cifrado puede hacer ilegibles datos existentes. Cambiar un secreto de sesión puede cerrar sesiones activas, lo cual puede ser aceptable, pero debe entenderse.

Reemitir cuando sea más seguro

Algunos elementos pueden recrearse: certificados, tokens o contraseñas. Si existe sospecha de exposición, la recuperación es un buen momento para revocarlos y emitir otros nuevos, siempre que se actualicen todas las dependencias.

Restaurar volúmenes y datos persistentes

Los datos persistentes son normalmente la parte más delicada de la recuperación. Las imágenes pueden volver a descargarse; los datos únicos no.

Identificar el tipo de almacenamiento

Antes de copiar nada, determina si el servicio usaba:

• named volumes;
• bind mounts;
• almacenamiento externo;
• base de datos separada;
• objetos en un servicio externo;
• una combinación de varios sistemas.

Crear primero el destino correcto

Si se van a restaurar bind mounts, recrea las rutas y permisos esperados. Si se usan named volumes, puede ser conveniente crear el volumen y después cargar en él los datos mediante un procedimiento controlado.

Preservar permisos y propietarios

Copiar archivos sin conservar propietarios, modos o atributos necesarios puede dejar una aplicación aparentemente completa pero incapaz de leer o escribir.

No mezclar datos antiguos y nuevos accidentalmente

Si el contenedor arranca antes de finalizar la restauración, puede crear archivos nuevos en el volumen. Después, al copiar encima una copia anterior, quedan dos estados mezclados. Es preferible restaurar con los servicios detenidos y arrancar solo cuando el conjunto esté preparado.

Comprobar capacidad

Una restauración puede requerir espacio adicional para archivos temporales, descompresión o dumps. Verifica el almacenamiento antes de comenzar para evitar una interrupción a mitad del proceso.

Restaurar bases de datos con consistencia

Una base de datos no debe tratarse como un conjunto de archivos cualquiera. La forma correcta de recuperación depende del motor, del método de copia y del estado en el que se obtuvo el backup.

Preferir procedimientos propios del motor cuando corresponda

Si existe un dump lógico, suele restaurarse mediante las herramientas del motor. Si se dispone de una copia física preparada específicamente, debe seguirse el procedimiento correspondiente. Copiar directorios de datos entre versiones incompatibles puede producir fallos difíciles de diagnosticar.

Verificar versión

Antes de restaurar, comprueba qué versión del motor utilizaba la aplicación. Una actualización de versión mayor durante una emergencia puede introducir migraciones de formato que no estaban previstas.

Restaurar primero la base y después la aplicación

En muchos casos conviene:

1. levantar únicamente el motor de base de datos;
2. crear usuarios y estructura necesaria;
3. restaurar el backup;
4. realizar comprobaciones básicas;
5. arrancar después la aplicación que consume esos datos.

Comprobar más que el arranque

Una base puede iniciar sin errores y contener tablas incompletas. Conviene comprobar recuentos, registros recientes, relaciones y funciones relevantes de la aplicación.

Definir el orden de recuperación

En una plataforma con varios servicios, el orden importa. Arrancar todo simultáneamente puede generar errores en cascada y dificultar el diagnóstico.

Un orden conceptual razonable puede ser:

1. host y almacenamiento;
2. Docker y herramientas básicas;
3. redes;
4. secretos y configuración;
5. bases de datos y almacenamiento persistente;
6. servicios de infraestructura compartida;
7. aplicaciones principales;
8. proxy inverso o entrada pública;
9. automatizaciones;
10. monitorización y tareas auxiliares.

Este orden no es universal. Si el proxy gestiona certificados o descubrimiento necesario para otros servicios, puede necesitar adelantarse. Lo importante es conocer las dependencias y evitar que el orden sea accidental.

Una infraestructura con varios servicios independientes debería hacer explícitas estas relaciones, como se plantea en cómo estructurar un entorno Docker para varios servicios independientes.

Arrancar servicios de forma controlada

Una vez preparados los datos y configuraciones, conviene levantar los proyectos por fases y observar cada transición.

Primer arranque

Para un proyecto Compose:

docker compose up -d

Después revisa:

docker compose ps
docker compose logs --tail=200

Si el servicio incorpora healthchecks, su estado aporta información útil, aunque no sustituye una validación funcional.

No ignorar errores porque “al final arranca”

Reintentos continuos contra una base de datos, errores de permisos, migraciones repetidas o fallos de autenticación pueden no detener el contenedor, pero indican que la recuperación no está limpia.

Registrar cada cambio

Durante una recuperación es fácil aplicar pequeñas correcciones que después nadie recuerda. Anota los cambios realizados para poder reproducir el estado final y actualizar la documentación.

Validar la plataforma después de restaurarla

La validación debe realizarse por capas. Una prueba superficial puede dejar errores ocultos que aparecen horas después.

1. Estado de infraestructura

• host estable;
• disco con espacio suficiente;
• memoria y CPU dentro de rangos razonables;
• Docker sin errores relevantes;
• redes creadas correctamente.

2. Estado de contenedores

• contenedores esperados activos;
• sin bucles de reinicio;
• healthchecks correctos cuando existan;
• logs sin errores persistentes.

3. Estado de datos

• volúmenes montados en la ubicación correcta;
• permisos válidos;
• bases de datos accesibles;
• registros recientes presentes hasta el punto esperado;
• archivos y adjuntos recuperados.

4. Estado funcional

Prueba funciones reales de cada aplicación. No basta con cargar una pantalla de inicio. Si el servicio procesa formularios, genera documentos, consulta datos o ejecuta tareas, prueba esas acciones.

5. Estado de integración

• correo saliente;
• APIs externas;
• webhooks;
• tareas programadas;
• DNS;
• certificados;
• monitorización;
• backups posteriores a la recuperación.

6. Validación desde fuera

Cuando el servicio es accesible por red, realiza alguna prueba desde un equipo distinto al host. Esto permite detectar errores de firewall, DNS, proxy o rutas que una prueba local no revela.

Qué hacer con los datos posteriores a la copia

Una copia representa un punto del pasado. Si el incidente ocurre después, puede existir un intervalo de información que no está incluido en el backup.

Ese intervalo debe tratarse conscientemente. Las posibilidades dependen del sistema:

• recuperar archivos supervivientes del host antiguo;
• reprocesar operaciones desde otra fuente;
• reconstruir registros a partir de exportaciones;
• reconciliar datos con sistemas externos;
• aceptar una pérdida conocida cuando no existe otra fuente.

No mezclar manualmente sin trazabilidad

Copiar “lo que parece más nuevo” desde el sistema dañado hacia el restaurado puede introducir inconsistencias. Si hay que reconciliar información, conviene identificar qué datos se incorporan, de qué origen proceden y cómo se comprueba el resultado.

RPO real

El incidente permite comprobar si la pérdida máxima tolerable definida en la política de copias era realista. Si una copia diaria implica perder veintitrés horas de información y eso resulta inaceptable, la política deberá cambiar después.

Recuperación cuando existe sospecha de intrusión

Una recuperación después de una intrusión debe ser más estricta que una recuperación tras una avería.

Si existe la posibilidad de que un atacante haya obtenido acceso al host, no conviene asumir que archivos, imágenes locales o credenciales siguen siendo confiables.

Tratar el host como no confiable

La reconstrucción sobre un sistema limpio suele ser preferible a intentar “limpiar” el servidor comprometido sin conocer el alcance.

Rotar credenciales

Pueden requerir rotación:

• contraseñas;
• tokens de API;
• claves SSH;
• credenciales de registros;
• secretos de aplicaciones;
• certificados o claves privadas expuestas.

Revisar imágenes

Evita reutilizar imágenes locales cuya integridad no puedas demostrar. Reconstruye desde fuentes confiables o vuelve a descargarlas de registros conocidos.

Preservar evidencia

Si el incidente puede requerir investigación, conserva registros y copias del estado afectado antes de sobrescribirlo. Recuperar servicio y analizar causa son objetivos distintos y ambos pueden ser necesarios.

No devolver inmediatamente todo a Internet

Primero valida el entorno restaurado y revisa el vector de entrada. Si se publica de nuevo el mismo servicio vulnerable sin corregir la causa, la recuperación puede durar muy poco.

Revisar dependencias externas

Una plataforma Docker puede estar perfectamente restaurada y seguir fallando por dependencias que viven fuera del servidor.

Conviene revisar:

• registros DNS;
• direcciones IP autorizadas;
• firewalls externos;
• registros de correo;
• APIs y tokens;
• servicios de almacenamiento;
• registros privados de imágenes;
• repositorios;
• monitorización externa;
• webhooks que apuntaban a una IP antigua;
• certificados vinculados a determinados dominios;
• copias que enviaban datos a otro sistema.

El cambio de IP es especialmente importante

Al reconstruir en otro host puede cambiar la IP pública o privada. Ese cambio puede afectar DNS, listas blancas, conexiones de bases externas, firewalls y sistemas de monitorización.

Comprobar tareas programadas

Algunas tareas se ejecutan dentro de contenedores; otras estaban en el host mediante cron, systemd timers o scripts. Si solo se restauran los proyectos Docker, estas tareas pueden quedar olvidadas.

Documentar la recuperación

Una incidencia grave genera conocimiento que no debería perderse. La documentación posterior permite convertir una recuperación improvisada en un procedimiento repetible.

Conviene registrar:

• fecha y hora del incidente;
• síntomas iniciales;
• causa confirmada o probable;
• servicios afectados;
• datos perdidos;
• última copia utilizada;
• host de recuperación;
• versiones restauradas;
• orden de recuperación;
• problemas encontrados;
• cambios realizados;
• tiempo hasta recuperar funciones esenciales;
• tiempo hasta la recuperación completa;
• comprobaciones efectuadas;
• acciones preventivas pendientes.

Distinguir procedimiento y cronología

La cronología explica qué ocurrió en este incidente. El procedimiento explica qué debería hacerse la próxima vez. Son documentos relacionados, pero no idénticos.

Actualizar el inventario

Si durante la recuperación se descubrió una dependencia no documentada, debe añadirse al inventario. Si una ruta había cambiado, hay que corregir la documentación. Si una credencial estaba en un lugar inseguro, debe trasladarse a un mecanismo adecuado.

Convertir el incidente en mejoras concretas

Una recuperación completa es también una prueba de arquitectura. Revela qué partes eran realmente reproducibles y cuáles dependían de conocimiento implícito.

Preguntas que conviene responder después

• ¿Se sabía qué servicios existían?
• ¿Se conocían las dependencias?
• ¿Las copias estaban accesibles?
• ¿Se sabía qué versión de cada imagen restaurar?
• ¿Los secretos estaban disponibles de forma segura?
• ¿La documentación estaba fuera del host perdido?
• ¿Se pudo reconstruir Docker sin copiar el estado interno del servidor?
• ¿Las bases de datos pudieron restaurarse sin improvisar?
• ¿Se conocía el orden de arranque?
• ¿Existían pruebas para validar las aplicaciones?
• ¿El RPO real fue aceptable?
• ¿El RTO real fue aceptable?

Priorizar las mejoras

No hace falta rediseñar todo después de una incidencia. Conviene corregir primero los puntos que más aumentaron el tiempo o el riesgo de recuperación.

Algunos ejemplos:

• versionar archivos Compose;
• fijar versiones de imágenes;
• separar datos del host;
• crear copias externas;
• probar restauraciones;
• documentar dependencias;
• automatizar reconstrucciones repetitivas;
• mantener un host alternativo preparado;
• reducir servicios innecesarios;
• mejorar monitorización.

La evolución de una plataforma debería planificarse sin perder recuperabilidad, como se explica en cómo planificar el crecimiento de una infraestructura Docker.

Procedimiento resumido paso a paso

El siguiente procedimiento resume una recuperación completa. Debe adaptarse a cada plataforma.

1. Detener cambios destructivos.

   Evita limpiezas, recreaciones o escrituras innecesarias sobre el sistema afectado.

2. Registrar el estado.

   Recoge síntomas, logs, recursos existentes y cambios recientes.

3. Clasificar el daño.

   Determina qué capas están intactas, dudosas o perdidas.

4. Decidir si reparar o reconstruir.

   No prolongues una reparación incierta cuando un host limpio sea más previsible.

5. Crear el inventario de recuperación.

   Ordena servicios por criticidad y dependencias.

6. Seleccionar fuentes confiables.

   Define de dónde saldrán configuración, imágenes, datos y secretos.

7. Preparar el host.

   Instala sistema operativo, Docker, Compose y requisitos básicos.

8. Recuperar proyectos.

   Restaura archivos Compose, configuraciones, scripts y documentación.

9. Preparar redes y almacenamiento.

   Recrea recursos necesarios sin arrancar prematuramente las aplicaciones.

10. Recuperar secretos.

    Restaura o rota credenciales según el tipo de incidente.

11. Restaurar datos.

    Recupera volúmenes, bind mounts y bases de datos mediante procedimientos consistentes.

12. Recuperar imágenes correctas.

    Utiliza versiones conocidas y evita cambios mayores durante la emergencia.

13. Arrancar por dependencias.

    Empieza por datos e infraestructura y continúa con aplicaciones y servicios periféricos.

14. Validar técnicamente.

    Revisa logs, healthchecks, recursos, redes y permisos.

15. Validar funcionalmente.

    Ejecuta operaciones reales de cada servicio.

16. Revisar dependencias externas.

    Comprueba DNS, certificados, APIs, correo, firewalls y automatizaciones.

17. Reactivar copias y monitorización.

    La plataforma restaurada debe volver a estar protegida desde el primer día.

18. Documentar.

    Registra el incidente y convierte lo aprendido en un procedimiento mejor.

Errores frecuentes durante la recuperación

Arrancar todos los servicios inmediatamente

Puede provocar escrituras sobre volúmenes incompletos, migraciones automáticas o errores en cascada. Recupera por capas.

Usar versiones nuevas durante el incidente

Cambiar simultáneamente de versión aumenta variables. Primero recupera el estado conocido; después actualiza de forma planificada.

Copiar todo el estado interno de Docker sin criterio

Puede trasladar corrupción o dependencias opacas. Cuando sea posible, recrea contenedores y restaura únicamente lo persistente.

Confundir volumen con backup

Que un volumen haya sobrevivido a la eliminación de un contenedor no significa que esté protegido frente a la pérdida del host.

Restaurar archivos de base de datos como archivos normales

Las bases de datos necesitan procedimientos compatibles con el motor y el tipo de copia.

No preservar permisos

Los datos pueden estar presentes y seguir siendo inutilizables si el proceso del contenedor no tiene acceso correcto.

Olvidar secretos

Una aplicación sin credenciales puede arrancar pero fallar al utilizar base de datos, correo o APIs.

No revisar la IP del nuevo host

Puede dejar DNS, listas blancas, firewall y webhooks apuntando al sistema anterior.

No validar operaciones reales

Una página que responde HTTP 200 no demuestra que el servicio funcione por completo.

Reutilizar credenciales después de una intrusión

Si pudieron quedar expuestas, deben revocarse o rotarse.

Improvisar sin registrar cambios

La plataforma termina funcionando, pero nadie sabe exactamente cómo quedó. Eso dificulta la siguiente actualización o recuperación.

Declarar el incidente cerrado demasiado pronto

Después de recuperar funciones principales hay que confirmar copias, monitorización, tareas programadas y dependencias secundarias.

Lista de comprobación

Preguntas frecuentes

Conclusión

Restaurar una plataforma Docker tras un fallo grave exige pensar en el sistema completo, no en una colección de contenedores. El host, las definiciones de despliegue, las imágenes, las redes, los secretos, los volúmenes, las bases de datos y las dependencias externas forman parte de la recuperación.

La respuesta más segura empieza por detener cambios innecesarios, clasificar el daño y decidir conscientemente si conviene reparar o reconstruir. Después, cada capa debe recuperarse desde fuentes confiables y en un orden compatible con sus dependencias.

Una plataforma Docker está realmente preparada para fallar cuando puede reconstruirse sobre un host limpio sin depender de memoria personal, datos ocultos ni piezas irrepetibles.

La validación final debe demostrar que los servicios funcionan de extremo a extremo, que los datos son coherentes, que las integraciones externas responden y que las copias y la monitorización vuelven a proteger el entorno restaurado.

El incidente también debe dejar una mejora permanente: documentación más precisa, versiones mejor controladas, backups probados, dependencias visibles y un procedimiento de recuperación que la próxima vez reduzca incertidumbre. Aprender a recuperar es, en última instancia, aprender a diseñar infraestructura más resistente y comprensible.