Iñigo GonzálezIT Operations · Infra

Blog · 32

El backup corrió cada noche, pero ¿devolvería el sistema? Una revisión mensual de backups, pruebas de restauración y DRThe backup ran every night, but would it bring the system back? A monthly review of backups, restore tests and DR

El último backup bueno de cada sistema frente a su RPO, las copias offsite e inmutables que de verdad se hicieron, las pruebas de restauración frente al plan y al RTO, y los ejercicios de DR y sus acciones, por sistema y nivel, en rojo, ámbar o verde.The last good backup of each system against its RPO, offsite and immutable copies that actually ran, restore tests against the plan and the RTO, and the DR exercises and their actions, per system and tier, in red, amber or green.

Herramientas de IT OpsIT Ops tools · 25 oct 202625 Oct 2026 · 3 min3 min read

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.

The problem

A green backup dashboard says the jobs ran. It does not say the system can be brought back within the time the business was promised. A job scheduled every night that failed three nights in a row is three days outside a 24-hour RPO. A copy job that exists but has failed for a week leaves the system with one copy, in one place. Restoring a file proves the backup is readable, not that the ERP comes back in four hours. A test where "the database came back but the application could not log in" is exactly what a real recovery would hit. And an auditor counts the evidence, not the tests. The answers live in the backup console, a spreadsheet of tests, the change tickets and the continuity plan; the monthly review needs them side by side.

What I built

  • Backups: systems in scope with no backup job, the last good backup against each system's RPO, failure streaks, the offsite and immutable copies each tier requires, and jobs still running for retired or unknown systems.
  • Restore tests: systems never restored, last tests that failed or half worked, tests overdue against the plan for their tier, restores slower than the RTO (measured only on full restores), systems only tested with file or item restores, and tests with no evidence.
  • DR exercises: the last exercise, exercises planned and not done, and actions past their due date.
  • report.html with tier 1 at a glance and a 12-month calendar of tests due, restore-review.md as the agenda, tests-due.csv with booked and done columns, failing-backups.csv and evidence-pack.csv for the auditor.
  • A read-only PowerShell exporter for Veeam job sessions; other tools' job reports work as CSV.

How it is built

Python with the standard library only. The demo is a made-up manufacturer with 76 systems in three tiers, two weeks of job runs, a year of restore tests and its DR exercises, with the problems placed on purpose. 13 tests, a runbook for the monthly review, and a GitHub Actions workflow that runs the tests and rebuilds the demo data and the screenshot.

What I learned

From my work with Veeam Backup and Commvault, and tape backups earlier on, designing and testing backup and DR plans, and supervising DR and business continuity tests aligned with ISO 22301. The lesson that shaped the tool is that the question is never "did the job run?" but "when did we last prove we can get this system back, how long did it take, and where is the evidence?". Measuring the RPO from the last good backup and the RTO only from full restores is what turns a green dashboard into an honest one.

Next steps

  • Run it first on the tier 1 systems with one month of real exports, and agree the test frequency per tier with the service owners.
  • Schedule the Veeam export for the first Monday of the month and keep each month's output folder.
  • Use tests-due.csv to book the next month's restore tests in the change calendar, tier 1 first.

Want to bring it to your environment or adapt it to your case? Get in touch and we can look at it together.

Tech Career Lab · newsletter

¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.

Apúntate y llévate las 33 ideasSign up and get the 33 ideas →