El respaldo corre todas las noches, decía el administrador con seguridad. Cuando pedimos ver el registro de la última ejecución, no había ninguno. No porque el respaldo hubiera fallado: porque no existía un registro que mostrar, ejecutado como un script en un cron job silencioso, sin logs consultables más allá de un archivo de texto en el servidor.
Lo que descubrimos al revisar
El proceso de respaldo era funcionalmente correcto: un script Python que exportaba las bases de datos críticas todas las noches a un almacenamiento externo. El problema era la falta de visibilidad. Si el script fallaba a mitad de camino —por espacio insuficiente, por una credencial vencida, por lo que fuera— nadie se enteraba hasta que alguien necesitaba restaurar algo y descubría que la última copia útil tenía dos semanas.
Eso fue exactamente lo que pasó, aunque en una prueba controlada y no en una emergencia real: al simular una restauración, encontramos que las últimas cuatro ejecuciones habían fallado silenciosamente por un problema de permisos tras una actualización del servidor de destino. El script seguía “corriendo”. No estaba respaldando nada.
Por qué migramos el proceso a Apache Airflow
No fue por reemplazar una herramienta que funcionaba por otra más de moda: la automatización de respaldos con Apache Airflow resolvía un problema concreto de visibilidad. Fue porque un DAG de Apache Airflow orquestando el mismo proceso deja algo que el cron job no dejaba: un registro de cada ejecución, con estado explícito de éxito o falla, y una alerta automática si algo no completa como se espera. La diferencia no está en qué tan bien escrito está el script de respaldo. Está en que alguien —o algo— se entera cuando falla, en vez de descubrirlo meses después.
El resultado
El mismo proceso de respaldo, ahora orquestado por Apache Airflow, con verificación de integridad después de cada ejecución y alerta inmediata si algo se detiene a mitad de camino. Cuando la primera auditoría interna del cliente pidió evidencia de que el respaldo efectivamente corre y funciona, la respuesta no fue una promesa verbal: fue el historial de ejecuciones de los últimos noventa días, con éxito confirmado en cada una.
La lección no es que el script anterior estuviera mal escrito. Es que un proceso sin registro, aunque funcione, no se puede demostrar. Y lo que no se puede demostrar, frente a una auditoría, es indistinguible de lo que no existe.
¿Tu proceso de respaldo genera un registro que puedas mostrar hoy mismo, o depende de la palabra de quien lo configuró?
