El backup que nunca se probó no es un backup: cómo verificar una restauración

Pregúntale a cualquier empresa si tiene respaldos y la respuesta será que sí. Pregúntale cuándo fue la última vez que restauró uno completo, en serio, y suele venir el silencio. Ahí está el problema: tener backup y poder recuperarte son dos cosas distintas, y la diferencia solo se descubre el peor día posible.

Un job en verde no es una restauración

La trampa más común es confiar en que el respaldo "corre bien". El trabajo termina, la consola marca verde, todos duermen tranquilos. Pero que una copia se haya escrito no dice nada sobre si se puede leer y levantar cuando haga falta. El verde confirma que el proceso terminó, no que el resultado sirve. Son garantías completamente diferentes, y confundirlas es la raíz de casi todos los desastres de recuperación.

Por qué fallan las restauraciones

Cuando llega el momento real, las restauraciones fallan por razones que casi nunca se ven de antemano:

• La copia está corrupta o incompleta: un medio dañado, un job que venía fallando en silencio, una copia escrita a medias.
• Faltan piezas: se respaldó el servidor de aplicación pero no la base de datos de la que depende, o al revés. Por separado, ninguno de los dos levanta.
• Nadie sabe el procedimiento: la persona que montó el respaldo ya no está, y el conocimiento de cómo recuperarlo se fue con ella.
• Las dependencias externas cambiaron: credenciales, licencias, direcciones, certificados que eran válidos cuando se respaldó y ya no al restaurar.

Ninguno de estos problemas se detecta mirando la consola. Todos se detectan intentando restaurar.

Cómo se verifica de verdad

Verificar un backup significa restaurarlo, no confiar en él. En la práctica se hace en capas: una verificación automática frecuente —herramientas como Veeam, con SureBackup, arrancan las máquinas respaldadas en un entorno aislado y comprueban que encienden y responden, sin tocar producción—; un simulacro completo periódico que restaura de verdad un sistema crítico con su procedimiento y sus dependencias; y la documentación del procedimiento, escrita, actualizada y guardada fuera del sistema que podría caerse.

El número que revela el simulacro

Ese ensayo entrega un dato valiosísimo que nadie tiene hasta que lo mide: el RTO real. Es habitual que una empresa "asuma" que restaurar su ERP toma dos horas y, en el primer simulacro honesto, descubra que fueron nueve —entre localizar la copia, levantar dependencias y reconfigurar—. Mejor descubrir ese número en un ensayo que en una crisis, cuando cada hora cuesta de verdad (y conviene ponerle precio con el costo del downtime).

Sí, cuesta tiempo. Cuesta menos que fallar

Probar restauraciones consume horas y disciplina, y es fácil posponerlo porque "nunca ha pasado nada". Pero el cálculo honesto es simple: el costo de un simulacro trimestral es una fracción minúscula del costo de descubrir, con el negocio detenido, que el backup en el que confiabas no servía. Esa disciplina es parte de un servicio serio de protección de datos. Un respaldo que nunca probaste no es un seguro: es una suposición.

Un backup probado es la base; encima van la inmutabilidad contra ransomware y, cuando el RTO aprieta, entender la diferencia entre backup y DRaaS.