Hay una frase incómoda que circula entre administradores de sistemas: una copia de seguridad que no se ha restaurado nunca no es una copia de seguridad, es una esperanza. Suena a exageración hasta que te toca comprobarlo el día malo.
Por qué falla justo cuando la necesitas
El problema no es que las copias no se hagan. Casi siempre se hacen. El problema es que hacer la copia y poder recuperarla son dos cosas distintas, y solo la primera se verifica sola.
Los fallos que aparecen únicamente al restaurar son siempre los mismos: la copia se completaba pero el fichero estaba corrupto; el volcado de la base de datos se hacía con la máquina en marcha y quedó inconsistente; el sistema copiaba una carpeta que ya no era la de datos porque la aplicación cambió de ruta hace meses; la copia era correcta pero nadie sabía el procedimiento y se perdieron seis horas improvisando.
Ninguno de estos problemas da la cara en un informe de copia correcta. Todos aparecen la primera vez que restauras.
Qué debe demostrar una prueba de verdad
Una prueba de restauración útil no es abrir la copia y ver que hay ficheros dentro. Tiene que responder cuatro preguntas con datos:
- ¿Se recupera el sistema completo? Arrancado, no solo descomprimido.
- ¿Cuánto tarda? Cronometrado. Ese número es tu tiempo de recuperación real, y sirve para poner expectativas antes de una crisis, no durante.
- ¿Los datos son consistentes? Las bases de datos, sobre todo. Que arranquen y que respondan a una consulta.
- ¿Está escrito el procedimiento? Porque el día que haga falta puede no estar disponible quien lo sabe de memoria.
Cómo hacerla sin riesgo
La regla de oro: restaura siempre a un destino nuevo, nunca sobre el original. Un identificador distinto, y con la interfaz de red desconectada.
Ese último detalle importa más de lo que parece. Una restauración conserva la configuración de red original, así que si la levantas conectada tendrás dos máquinas peleándose por la misma IP y romperás el servicio en producción mientras hacías una prueba de seguridad. Levántala con la red desconectada, verifica desde la consola, y destrúyela al acabar.
Con qué frecuencia
Trimestral es un buen punto de partida para la mayoría. Y siempre, obligatoriamente, después de un cambio relevante: una migración, una actualización mayor, un cambio en la estructura de datos o en la política de copias. Los cambios son precisamente lo que rompe las copias sin avisar.
Un ejemplo con números
Nuestra última prueba documentada, hecha sobre un servidor real y no sobre un caso de laboratorio: restauración completa desde nuestro centro de datos principal en 33 segundos, y desde el segundo centro de datos en 58 segundos, en las dos ocasiones sobre un nodo físico distinto al original.
Lo interesante de esos números no es que sean bajos. Es que existen: cuando un cliente nos pregunta cuánto tarda una recuperación, la respuesta no es una estimación, es una medición.
Lo que deberías pedirle a tu proveedor
Si tienes copias contratadas con alguien, la pregunta es directa: ¿cuándo fue la última restauración real que hicisteis, y cuánto tardó? Un proveedor que lo prueba tiene el dato a mano. Uno que no, improvisa una respuesta genérica.
Cómo lo hacemos
En nuestras copias de seguridad documentamos las pruebas de restauración con fecha, origen, destino y tiempos medidos. Y en el nivel gestionado, hacemos la prueba periódica por ti y te entregamos el informe. Todo dentro de nuestros dos centros de datos en Andorra.