La frase apareció en la primera reunión, dicha con total tranquilidad: los respaldos funcionan, corren todas las noches y nunca han dado problemas. Era verdad. El sistema llevaba dos años ejecutándose cada noche y reportando éxito. Nadie mentía.
En nuestro proceso estándar de diagnóstico hay un paso que no negociamos: restaurar un respaldo como prueba, con el equipo técnico del cliente presente. No porque sospechemos algo. Porque es la única forma de saber con certeza.
Lo que apareció al restaurar cambió las prioridades del proyecto entero.
Lo que encontramos
Al buscar el servidor de la aplicación de gestión interna en el inventario de respaldos, no estaba. El trabajo de respaldo se había configurado dos años antes con una lista explícita de las VMs que existían en ese momento. Todo lo creado después — entre ello, el servidor de gestión que se había migrado a una VM nueva hacía más de un año — quedó fuera. El trabajo nocturno terminaba en éxito porque respaldaba, fielmente, una lista desactualizada.
El segundo hallazgo: de las máquinas que sí estaban en la lista, algunas copias antiguas no pasaron la restauración. El destino de almacenamiento de respaldo había llegado a su límite meses atrás, y algunas copias habían quedado incompletas. Sin trabajos de verificación configurados, nadie lo sabía.
Resultado: dos años de luces verdes, y la empresa no podía recuperar su sistema principal si lo hubiera necesitado.
Por qué pasó esto — y por qué no es negligencia
El administrador configuró bien el respaldo con lo que existía en ese momento. El sistema hizo exactamente lo que se le pidió. El problema es estructural: un respaldo configurado una vez y nunca revisado se va desacoplando silenciosamente de la realidad que debe proteger. Las VMs nuevas no se agregan solas a la lista. Los destinos de almacenamiento se llenan. Y el reporte de éxito responde una pregunta distinta a la que el gerente cree que responde: dice que el trabajo terminó, no que la empresa puede recuperarse.
Desde diciembre, con la Ley 21.719 en vigor, esa distinción importa más que antes. Si ocurre un incidente con datos de clientes, la primera pregunta no va a ser si tenían respaldo: va a ser si ese respaldo era real y si podían usarlo. La diferencia entre “el trabajo de respaldo corrió” y “restauramos el sistema en cuarenta minutos siguiendo el procedimiento documentado” es exactamente la diferencia que van a buscar.
Lo que se implementó
Las prioridades del proyecto se reordenaron ese mismo día. Primero: cobertura por defecto de todo el entorno — cada VM nueva queda respaldada sin depender de que alguien lo recuerde. Segundo: verificación automática de integridad con alertas. Tercero: una copia remota cifrada que no existía. Cuarto: prueba de restauración mensual documentada, ejecutada por el propio equipo del cliente. La primera la hicimos juntos. Las siguientes son de ellos.
Un respaldo sin prueba de restauración no es un respaldo: es una hipótesis. Y desde diciembre, las hipótesis no son suficientes.
¿Tu empresa puede decir hoy — con un registro, no con una suposición — que sus datos personales críticos son recuperables?
