En los diagnósticos de seguridad, una escena se repite con frecuencia incómoda: la empresa tiene backups configurados, el proceso corre automáticamente cada noche, el panel marca “éxito” en verde. Hasta ahí, todo bien. Cuando se pide probar una restauración de verdad —tomar un archivo aleatorio y recuperarlo en un equipo distinto— aparecen las sorpresas.
Backup que no se puede abrir porque la versión del software cambió. Archivos que se respaldan pero una carpeta crítica no está incluida. Claves de cifrado que nadie recuerda. Medios que no se leen en otro equipo. Copias que alcanzan los 7 días pero el incidente se detecta en el día 10. Todos esos problemas existen desde el primer día; lo que pasa es que nadie los ve hasta que hacen falta.
La solución no es compleja ni cara: probar la restauración, de forma sistemática y con cierta frecuencia. El costo de hacerlo es una fracción del costo de descubrirlo durante un incidente real.
Por qué los backups fallan silenciosamente
Varias causas, todas comunes, hacen que un backup aparentemente exitoso no sirva cuando hace falta:
El archivo del backup se corrompe. El medio (disco, cinta, almacenamiento cloud) tiene un error físico, una escritura parcial, un problema en la red al subir. El proceso de backup no siempre verifica la integridad después.
El software de backup cambió de versión y ya no abre las copias viejas. Particularmente con cintas y con formatos propietarios, migraciones de versiones pueden dejar archivos históricos inaccesibles.
Lo que se respalda no es todo lo crítico. Se agregaron carpetas nuevas después de configurar el backup y nadie actualizó la lista. La información nueva queda fuera, sin que se note.
El tiempo de retención es insuficiente. El backup se hace todos los días pero solo se guardan los últimos 7. Un problema detectado 10 días después (corrupción silenciosa, infección que actuó gradualmente) ya no tiene copia limpia.
La clave de cifrado se perdió. El backup está cifrado correctamente, pero la contraseña la tenía alguien que ya no trabaja en la empresa y no está documentada.
El medio físico se deterioró. Discos externos guardados mal, cintas desmagnetizadas, pendrives en el cajón que ya no leen.
Cada uno de estos fallos es detectable antes del incidente, pero solo si se mira.
Qué significa “probar un backup”
Hay tres niveles, de menor a mayor esfuerzo y garantía:
Nivel 1 — Verificación automática: el software de backup, al terminar, lee lo que acaba de escribir y lo compara con el original. Detecta errores de integridad. La mayor parte de los productos serios lo hacen. Pero no detecta si la lista de archivos respaldados es completa, ni si el backup va a poder restaurarse en un equipo nuevo.
Nivel 2 — Restauración parcial: una vez por mes, tomar un archivo o una carpeta al azar del backup más reciente y restaurarla en un equipo diferente al original. Verificar que se puede abrir, que el contenido coincide, que las fechas son correctas. Lleva entre 15 y 30 minutos. Detecta la mayoría de los problemas silenciosos.
Nivel 3 — Restauración completa a equipo alternativo: una vez por trimestre o semestre, armar un simulacro de “caída total”: tomar el último backup y levantar el servidor entero en un equipo de prueba (una PC separada, una máquina virtual, un Proxmox de testing). Medir cuánto tiempo tarda, si todo vuelve a funcionar, si aparecen problemas inesperados. Lleva entre media jornada y una jornada completa, pero es la única manera de saber cuánto tarda realmente una recuperación.
Los tres niveles son complementarios. El 1 es obligatorio, el 2 debería ser rutina, el 3 vale la pena al menos dos veces al año.
Quién se hace cargo
El testeo de backups suele ser tarea de nadie, y por eso no se hace. Dos decisiones resuelven el problema:
Un responsable asignado. Puede ser el proveedor IT externo o alguien interno, pero tiene que haber un nombre. Sin responsable, el testeo no ocurre.
Un calendario fijo. Por ejemplo: primer lunes de cada mes, restauración parcial. Primer lunes de cada trimestre, restauración completa. Con alarmas automáticas y registro de lo que se hizo.
El registro es importante: no alcanza con “hace unos meses probamos”. Tiene que quedar por escrito cuándo se probó, qué se restauró, cuánto tardó, qué problemas aparecieron. Ese historial es la prueba de que el respaldo funciona, y también es el insumo para mejorar el proceso.
Los escenarios que hay que estar en condiciones de resolver
Los simulacros deberían contemplar los tres casos más probables:
Archivo borrado o modificado por error. Alguien borra una carpeta importante, o la sobrescribe con contenido erróneo. Necesito recuperar esa carpeta tal como estaba, por ejemplo, hace 3 días. Es el caso más frecuente y el más simple de resolver si el backup guarda versiones.
Ransomware que cifra los datos. Un equipo infectado cifra archivos en la red. Necesito restaurar desde la copia más reciente que no esté infectada. Acá aparecen preguntas incómodas: ¿la copia en el NAS está también cifrada? ¿desde cuándo el incidente viene en curso? El backup tiene que tener versiones antiguas suficientes para poder elegir una limpia.
Falla total del servidor. El servidor principal muere, hay que levantar todo en otro equipo. Es el escenario de “lunes a las 8 a la mañana” que explica por qué la restauración completa hay que probarla.
Si en el ejercicio de restauración los tres casos salen bien, el respaldo cumple su función. Si alguno falla, mejor enterarse ahora que en el incidente real.
El costo de no testear versus el costo de testear
Testear un backup parcialmente lleva 30 minutos por mes. Una restauración completa, una jornada por trimestre. Para una empresa con proveedor IT externo, es tiempo incluido en el abono o un pequeño trabajo extra.
El costo de no testear: descubrir durante el incidente real que el backup estaba corrupto, que la carpeta crítica no se respaldaba o que la clave de cifrado se perdió. El incidente ya trae sus propios costos; agregarle la sorpresa de no tener respaldo es convertir un problema resoluble en una catástrofe.
¿Cuándo fue la última vez que alguien en tu empresa tomó un archivo al azar del último backup y verificó que se podía abrir correctamente? Si la respuesta es “no sé” o “hace mucho”, probablemente hay tiempo justo para descubrir problemas antes de que aparezcan. Probarlo una vez alcanza para saber dónde se está parado.
