Un respaldo que nadie ha restaurado es una hipótesis

Casi todas las empresas tienen respaldos. Muy pocas tienen restauraciones. Y hasta que alguien no restaura, lo que hay no es una copia de seguridad: es una hipótesis con buena reputación.

El trabajo diario refuerza el malentendido. El agente de respaldo reporta «correcto» todas las noches, el tablero se pinta de verde y nadie pregunta más. Pero ese «correcto» dice que el archivo se escribió, no que el negocio pueda volver a funcionar con él.

Qué aparece la primera vez que se restaura de verdad

La primera prueba de restauración de un ambiente que nunca se probó casi siempre encuentra algo. No porque el equipo lo haya hecho mal, sino porque hay cosas que solo se ven restaurando:

• Dependencias que nadie anotó. La base vuelve, pero la aplicación no arranca porque faltan certificados, cadenas de conexión, tareas programadas o un servicio que vivía en otra máquina.
• El orden. Restaurar la aplicación antes que la identidad, o los datos antes que el almacenamiento donde deben quedar, convierte una recuperación en dos.
• El tiempo real. Se creía que era «un par de horas» y resultan seis, casi todas esperando la copia desde almacenamiento frío.
• Lo que no estaba respaldado. Un disco agregado después de configurar la política. Una máquina nueva que nadie incluyó. Un archivo de configuración que vivía fuera de la carpeta de la aplicación.
• Quién sabe hacerlo. Si el procedimiento existe solo en la cabeza de una persona, el plan de continuidad depende de que esa persona conteste el teléfono.

Por qué va en el contrato, no en las buenas intenciones

Una prueba de restauración cuesta tiempo de gente y una ventana de trabajo. Como todo lo que cuesta y no es urgente, se aplaza. Por eso en nuestros servicios administrados la prueba trimestral es una obligación escrita, con su evidencia y su fecha, y no un compromiso verbal: escrita, alguien tiene que ejecutarla y alguien tiene que revisar que se ejecutó.

Es la misma lógica de todo lo demás que medimos. La disponibilidad se reporta por servidor con la causa de cada evento; la seguridad, con la evolución del Secure Score; los respaldos, con una restauración que ocurrió de verdad. Lo que no se verifica, con el tiempo, deja de ser cierto sin que nadie lo note.

Qué debería incluir una política que sí sirve

• Respaldo separado por tipo de carga: no es lo mismo el sistema operativo que la aplicación que los datos, y no tienen la misma frecuencia ni la misma retención.
• Retención declarada en días, semanas y meses, alineada con lo que exige el negocio y con lo que exige el regulador, que no siempre coinciden.
• Una copia fuera del alcance de las credenciales del día a día. Un respaldo que se puede borrar con la misma cuenta que administra el servidor no protege del escenario que más preocupa.
• Prueba trimestral con evidencia: qué se restauró, dónde, cuánto tardó y qué falló.
• Un tiempo objetivo de recuperación acordado con el negocio, no heredado del catálogo del proveedor.

El valor no es el archivo: es el número

Al final, el entregable de una buena política de respaldos no es una carpeta llena de copias. Es una frase que alguien puede decir en una reunión sin cruzar los dedos: «si esto se cae hoy, volvemos en tantas horas, y lo sabemos porque lo hicimos en julio».

Si no tiene ese número, o lo tiene pero nadie lo ha comprobado este año, hablemos.