Guía · Recuperación
Probar la restauración: solo la prueba hace una copia de seguridad
En resumen: «copia correcta» solo significa que se escribieron datos, no que un sistema vaya a arrancar de nuevo a partir de ellos. Solo una prueba de restauración periódica y documentada demuestra si una copia responde en una emergencia. Lo más fiable es que se ejecute automáticamente.
Por qué fallan las copias en una emergencia
La mayoría de las restauraciones fallidas tienen causas poco espectaculares que ningún mensaje de éxito revela:
- Un disco duro o una unidad nueva nunca se incluyó en la copia.
- La base de datos se copió en mitad de una escritura y no arranca limpiamente.
- La clave de una copia cifrada ya no se encuentra.
- Una carpeta ha ido encogiendo durante meses sin que nadie lo notara, porque una aplicación guarda sus datos en otro lugar.
- La máquina virtual arranca, pero se queda detenida en una pantalla de error.
- Nadie recuerda en qué orden deben arrancar los sistemas.
Qué comprueba una buena prueba de restauración
| Nivel | Qué se comprueba | Qué detecta |
|---|---|---|
| Datos legibles | Cada objeto guardado se lee y se compara con su suma de comprobación | Datos dañados o ausentes en el store |
| Restaurable | La copia se restaura por completo en una zona de prueba | Partes que faltan, claves erróneas, espacio insuficiente |
| Sistema de archivos intacto | Cada sistema de archivos se comprueba y se monta | Copias incoherentes, particiones defectuosas |
| Contenido plausible | Se lee cada archivo y se cuentan archivos y volúmenes de datos para compararlos con la última prueba | Archivos ilegibles o modificados sin que se note, zonas encogidas, vacías o desactualizadas |
| Sin rastros de ransomware | Se examinan los archivos en busca de indicios de cifrado: contenido que no corresponde a la extensión o parece aleatorio, extensiones típicas y notas de rescate | Copias que ya contienen datos cifrados |
| El sistema arranca | La máquina virtual se inicia en un entorno aislado | Sistemas que no arrancan, pantallas de error |
| El servicio responde | Un servicio como el directorio, el correo o la base de datos acepta conexiones | Sistemas que arrancan pero no funcionan |
¿Con qué frecuencia probar?
No hay un plazo legal, pero leyes como NIS2 y el RGPD exigen la verificación periódica de las medidas. Ha dado buen resultado:
- De diario a semanal: comprobación de los datos guardados; en stores grandes, solo de los recién añadidos.
- Semanal: una muestra, en la que algunas copias elegidas al azar se restauran por completo y se arrancan.
- Al menos una vez al año: una prueba de los sistemas más importantes en el orden correcto, midiendo el tiempo hasta que vuelven a estar operativos.
Más importante que la frecuencia es que cada prueba esté documentada: cuándo, qué copia, qué resultado. Una prueba sin evidencia no cuenta en una auditoría.
Probar sin riesgo para la operación
Una máquina restaurada nunca debe comunicarse con la red real: un segundo controlador de dominio o servidor de correo con el mismo nombre puede causar grandes daños en plena operación. Por eso las restauraciones de comprobación deben hacerse en un entorno aislado, sin red o en una red propia sin conexión al exterior. Allí, los sistemas dependientes arrancan en el orden correcto, por ejemplo primero el controlador de dominio y después el servidor de correo.
Cómo lo automatiza AegisGrid
El servidor de copias de AegisGrid ejecuta la restauración de comprobación como flujo de trabajo, por ejemplo cada sábado por la mañana con tres copias elegidas al azar: restaurar, comprobar los sistemas de archivos en modo de solo lectura y montarlos, leer cada archivo y compararlo con la última comprobación, arrancar las máquinas virtuales en un entorno QEMU/KVM aislado, comprobar si muestran imagen, escriben en sus discos o responden sus servicios, y limpiar después. El informe de comprobación llega por correo electrónico con un semáforo por disco y partición y capturas de pantalla de las máquinas arrancadas; cada prueba queda anotada con su resultado en el registro de evidencias firmado y en el informe mensual.
Preguntas frecuentes sobre la prueba de restauración
¿Basta con verificar las sumas de comprobación de la copia?
No. Un control de sumas de comprobación muestra que los datos guardados no han cambiado. Si la copia está completa y un sistema arranca a partir de ella solo lo demuestra una restauración.
¿Necesita una restauración de comprobación un entorno de pruebas propio?
Necesita espacio de almacenamiento para los datos restaurados y, para arrancar máquinas virtuales, un equipo con virtualización por hardware. El servidor de copias de AegisGrid incorpora el entorno aislado; no hace falta una infraestructura de pruebas propia.
¿Se pueden probar también copias cifradas?
Sí, para ello el servidor que realiza la prueba necesita la clave. Sin la clave siguen siendo posibles la comprobación de los datos guardados, la réplica y la limpieza.
Vea una restauración de comprobación en sus sistemas
En un proyecto piloto restauramos sus copias a modo de prueba, con informe y capturas de pantalla.