El backup corrió cada noche, pero ¿devolvería el sistema? Backups, restauraciones y DR cada mes

El problema

Un panel de backups en verde dice que los trabajos se ejecutaron. No dice que el sistema se pueda recuperar en el tiempo que se prometió al negocio. Un trabajo programado cada noche que ha fallado tres noches seguidas está tres días fuera de un RPO de 24 horas. Una copia que existe pero lleva una semana fallando deja el sistema con una sola copia, en un solo sitio. Restaurar un fichero demuestra que el backup se puede leer, no que el ERP vuelva en cuatro horas. Una prueba en la que "la base de datos volvió pero la aplicación no podía iniciar sesión" es justo lo que pasaría en una recuperación real. Y un auditor cuenta las evidencias, no las pruebas. Las respuestas están en la consola de backup, una hoja de pruebas, los tickets de cambio y el plan de continuidad; la revisión mensual necesita verlas juntas.

Qué he hecho

• Backups: sistemas en alcance sin trabajo de backup, el último backup bueno frente al RPO de cada sistema, rachas de fallos, las copias offsite e inmutables que exige cada nivel y trabajos que siguen corriendo para sistemas retirados o desconocidos.
• Pruebas de restauración: sistemas nunca restaurados, últimas pruebas fallidas o a medias, pruebas vencidas frente al plan de su nivel, restauraciones más lentas que el RTO (medido solo con restauraciones completas), sistemas probados solo con ficheros o elementos y pruebas sin evidencia.
• Ejercicios de DR: el último ejercicio, ejercicios planificados y no hechos, y acciones pasadas de fecha.
• report.html con el nivel 1 de un vistazo y un calendario de 12 meses de pruebas pendientes, restore-review.md como orden del día, tests-due.csv con columnas de reservado y hecho, failing-backups.csv y evidence-pack.csv para el auditor.
• Un exportador de solo lectura en PowerShell para las sesiones de Veeam; los informes de otras herramientas sirven en CSV.

Cómo está hecho

Python solo con la librería estándar. La demo es un fabricante inventado con 76 sistemas en tres niveles, dos semanas de trabajos, un año de pruebas de restauración y sus ejercicios de DR, con los problemas puestos a propósito. 13 tests, un runbook para la revisión mensual y un workflow de GitHub Actions que ejecuta los tests y regenera los datos de la demo y la captura.

Qué aprendí

De mi trabajo con Veeam Backup y Commvault, y antes con backups en cinta, diseñando y probando planes de backup y DR, y supervisando pruebas de DR y continuidad de negocio alineadas con ISO 22301. La lección que da forma a la herramienta es que la pregunta nunca es "¿se ejecutó el trabajo?", sino "¿cuándo demostramos por última vez que podemos recuperar este sistema, cuánto tardó y dónde está la evidencia?". Medir el RPO desde el último backup bueno y el RTO solo con restauraciones completas es lo que convierte un panel en verde en uno honesto.

Siguientes pasos

• Ejecutarlo primero con los sistemas de nivel 1 y un mes de exportaciones reales, y acordar la frecuencia de pruebas por nivel con los responsables de servicio.
• Programar la exportación de Veeam para el primer lunes de cada mes y guardar la carpeta de resultados de cada mes.
• Usar tests-due.csv para reservar las pruebas del mes siguiente en el calendario de cambios, empezando por el nivel 1.

¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.