Por qué un trabajo en verde no prueba nada
Las formas en que un respaldo técnicamente exitoso resulta inservible son conocidas y todas silenciosas. La más frecuente es el alcance: el trabajo copia lo que se le configuró hace tres años y, desde entonces, entró un disco nuevo, se movió una base de datos o alguien creó un recurso compartido que nunca se agregó. El respaldo termina perfecto y deja fuera la mitad de lo que importa.
Le siguen la cadena incremental rota por un eslabón corrupto, de modo que los puntos posteriores dejan de ser restaurables; la base de datos copiada en caliente sin el mecanismo que garantiza consistencia, que restaura pero no abre; la retención mal calculada, que borró la copia del día que hacía falta; y la copia que existe pero cuyo destino está lleno, inaccesible o con las credenciales vencidas desde hace semanas.
Ninguna de estas situaciones produce una alerta. Todas se detectan con una restauración de prueba, y únicamente con eso.
Los tres niveles de verificación
- Verificación de integridad. El software comprueba que la copia escrita coincide con lo que debía escribir, normalmente por suma de verificación. Es automática, debe estar activada y su resultado esperado es cero errores: es el último dígito de la regla 3-2-1-1-0. Detecta corrupción de la copia, no problemas de alcance ni de consistencia.
- Validación de arranque automatizada. La plataforma levanta la imagen respaldada en una máquina virtual aislada, confirma que el sistema operativo arranca y que los servicios responden, y después la apaga. Acronis Cyber Protect lo ejecuta de forma programada y entrega evidencia con fecha. Es la verificación con mejor relación entre esfuerzo y certeza: prueba lo que la integridad no prueba, sin ocupar a nadie.
- Restauración real a un entorno de prueba. Una persona recupera un conjunto definido de información a un equipo o a una máquina aislada, abre lo recuperado, revisa que el contenido sea el correcto y mide cuánto tardó. Es el único nivel que valida el procedimiento, la documentación y a la gente, no sólo el software.
La prueba de restauración: qué probar y cada cuánto
No hay que restaurar todo cada mes; hay que rotar. Un calendario que funciona en una empresa mediana se parece a esto:
- Cada mes: recuperar un conjunto de archivos de un servidor y de un buzón de correo, incluyendo algo de una fecha vieja para probar la retención, no sólo la copia de anoche.
- Cada trimestre: restaurar una máquina completa a un entorno aislado y abrir la aplicación que vive en ella. Aquí se prueban los sistemas de línea de negocio, que son los que más dependencias tienen.
- Cada trimestre: una restauración de base de datos con verificación del contenido por parte de quien lo usa, no de quien lo restauró. Que la base abra no quiere decir que los últimos movimientos estén.
- Cada año: el simulacro completo, con reloj, contra el RTO comprometido.
- Siempre que algo cambie: un servidor nuevo, una migración, un cambio de versión o un disco agregado obligan a verificar el alcance del trabajo de respaldo antes de dar por buena la siguiente copia.
El simulacro: probar la recuperación, no el archivo
La prueba mensual valida la herramienta. El simulacro valida a la empresa. Se anuncia la fecha, se parte de un supuesto concreto, por ejemplo que el servidor principal no existe y que el sitio no está disponible, y se ejecuta el procedimiento escrito tal como está, sin atajos ni ayudas de quien lo diseñó.
Lo que hay que medir es el tiempo hasta que el primer usuario puede trabajar de verdad, no hasta que el administrador ve el servidor encendido. Y lo que hay que anotar es dónde se detuvo el procedimiento: una contraseña que ya no era, un paso que faltaba, una dependencia que nadie había documentado, un enlace demasiado lento para bajar la copia. Esos hallazgos son el entregable del simulacro.
Un detalle que cambia el resultado: el simulacro debería ejecutarlo alguien que no sea quien administra el respaldo a diario. Si sólo lo logra esa persona, el plan depende de que esté disponible el día del incidente, y eso no es un plan.
Señales de que un esquema de respaldo no está sano
- Nadie recuerda la fecha de la última restauración, o la última fue durante un incidente real.
- Hay trabajos con advertencias que se toleran desde hace meses porque siempre aparecen.
- La lista de lo que se respalda no se compara nunca contra el inventario real de servidores y servicios.
- El respaldo se administra con la misma cuenta que el dominio y desde el mismo equipo.
- No hay ninguna copia inmutable ni aislada, sólo copias en recursos de red escribibles.
- El RPO y el RTO no están por escrito, así que no existe un criterio para decir si el esquema cumple o no.
- Las alertas llegan a una cuenta de correo que nadie revisa, o llegan tantas que se filtran automáticamente.
Qué debería poder mostrar el responsable de TI cada mes
La verificación se vuelve real cuando produce un documento corto y repetible. Un reporte mensual útil cabe en una página: porcentaje de trabajos completados sin error, lista de trabajos con advertencia y qué se hizo con ellos, inventario de sistemas protegidos comparado contra el inventario real, fecha y resultado de la restauración de prueba del mes con el tiempo que tomó, estado de la copia fuera del sitio y de la copia inmutable, y el margen de retroceso disponible hoy en días.
Con eso, la dirección deja de preguntar si hay respaldo, que es una pregunta sin respuesta útil, y empieza a preguntar por el dato del mes. Y cuando el dato falta, se nota.
En igeckoo ese reporte es parte del servicio administrado: monitoreo diario de los trabajos, pruebas de restauración programadas con evidencia y revisión del alcance cada vez que cambia la infraestructura.