Una consola de backup que muestra una larga serie de marcas verdes demuestra que los datos se escribieron en algún lugar. No demuestra que los datos puedan leerse de vuelta, que una aplicación pueda arrancar a partir de ellos, ni que todo el ejercicio quepa dentro de la ventana de recuperación que se ha prometido al negocio.
El ransomware ha cambiado la forma del problema. Antes, una recuperación significaba restaurar un servidor o una carpeta eliminada. Ahora, con frecuencia, significa restaurar de golpe un nivel completo de sistemas, en un entorno en el que no se puede confiar, mientras las personas que mejor conocen la infraestructura no tienen acceso a sus herramientas habituales.
Este artículo describe un programa práctico de pruebas de restauración: tres niveles de prueba, una frecuencia inicial para cada uno, las mediciones que realmente predicen el tiempo de recuperación, cómo registrar los resultados frente al RTO y el RPO, y las razones por las que los simulacros fallan con mayor frecuencia.
¿Qué son las pruebas de recuperación y por qué no basta con que el backup se complete?
Las pruebas de recuperación son el acto deliberado de restaurar datos o sistemas desde el backup en una ubicación controlada y confirmar que el resultado es completo, coherente y utilizable. Se distinguen de la monitorización de trabajos de backup, que solo informa de que la fase de escritura se completó, y de las funciones de verificación automatizada que arrancan una instantánea o comparan sumas de comprobación. Estas últimas son comprobaciones de confianza sobre una copia, no un ensayo del proceso que un equipo seguiría bajo presión.
El tiempo de recuperación está dominado por elementos que un trabajo de backup nunca ejercita: el rendimiento de la ruta de restauración, el orden en que deben volver los sistemas dependientes, la disponibilidad de credenciales y de DNS, y el tiempo que tardan las personas en tomar decisiones. Un simulacro de restauración mide todos ellos.
¿Cuáles son los tres niveles de pruebas de restauración?
Un programa viable prueba las cosas pequeñas con frecuencia, las medianas con regularidad y las grandes raramente pero con seriedad.
Nivel 1: comprobaciones puntuales de objetos y archivos individuales
La prueba más ligera restaura un archivo individual, un elemento de buzón, una tabla de base de datos o un objeto S3 desde un punto de backup seleccionado al azar y lo compara con una referencia conocida. El objetivo es la integridad del catálogo: si la aplicación de backup sabe dónde están los datos, si puede recuperarlos y si el contenido coincide. Estas comprobaciones son baratas y pueden automatizarse. Deberían rotar entre cargas de trabajo y antigüedades de backup, de modo que también se ejerciten los puntos de restauración más antiguos, incluidos los de un nivel inmutable.
Nivel 2: restauraciones a nivel de aplicación con validación
El nivel intermedio restaura una aplicación completa, normalmente una base de datos, un servidor de archivos o un sistema de negocio con sus dependencias, en un segmento de red aislado. El éxito no consiste en que las máquinas virtuales se enciendan. El éxito consiste en que el responsable de la aplicación inicie sesión, ejecute un conjunto acordado de consultas o transacciones de validación y dé su conformidad. Aquí es donde afloran los problemas latentes, como una base de datos restaurada que arranca pero no puede alcanzar su fuente de autenticación.
Nivel 3: ensayos de restauración masiva de un nivel completo
La prueba más exigente restaura un nivel completo de sistemas en paralelo en una clean room (entorno de recuperación aislado): un entorno recién construido y aislado, con su propia identidad, red y herramientas de gestión, que se asume libre de cualquier presencia del atacante. Es la única prueba que mide el rendimiento agregado de restauración bajo una carga realista, expone problemas de orden entre sistemas y ensaya el plan de respuesta a incidentes. Debería ejecutarse como un ejercicio con un escenario, un encargado de tomar notas y una sesión de análisis posterior.
¿Con qué frecuencia debería ejecutarse cada nivel?
La frecuencia debe seguir la criticidad de la carga de trabajo y el coste de la prueba, y debe ajustarse a partir de la evidencia. Si un ensayo de Nivel 3 descubre una dependencia que nadie había documentado, el siguiente debería adelantarse.
- Sistemas de nivel 1 (impacto en cuestión de horas): Nivel 1 semanal y automatizado cuando sea posible, Nivel 2 trimestral, Nivel 3 al menos anual y tras cambios significativos de infraestructura.
- Sistemas de nivel 2 (impacto en uno o dos días): Nivel 1 mensual, Nivel 2 dos veces al año, incluidos en el Nivel 3 de forma rotativa.
- Sistemas de nivel 3 (impacto en una semana): Nivel 1 trimestral, Nivel 2 anual, muestreados durante el Nivel 3 para confirmar que la ruta de restauración escala.
- Todos los niveles: una prueba no programada cada vez que la aplicación de backup, el destino de almacenamiento, el hipervisor o la plataforma de identidad cambien de versión.
Las organizaciones reguladas pueden tener mínimos prescritos. Las frecuencias anteriores no son un estándar, solo un punto de partida defendible.
¿Qué debería medir un simulacro de restauración?
Un simulacro que termina con un “ha funcionado” ha desperdiciado la mayor parte de su valor. Cinco mediciones convierten una prueba en datos que pueden compararse con los objetivos de recuperación acordados.
Rendimiento sostenido de restauración
Medido en terabytes por hora a lo largo de toda la ruta de restauración, no el pico de un único flujo. Supongamos que una organización tiene 200 TB en sus sistemas de nivel 1 y un RTO declarado de 24 horas. Necesita una tasa sostenida superior a aproximadamente 8,5 TB por hora, con margen, o el RTO es una ficción por muy bien que se hayan realizado los backups.
Tiempo hasta el primer sistema utilizable
Tiempo transcurrido desde la decisión de restaurar hasta que el primer sistema de nivel 1 queda validado. Recoge la sobrecarga fija de levantar la clean room y recuperar la identidad, que ninguna cifra de rendimiento revela.
Tiempo hasta el nivel completo
Tiempo transcurrido hasta que el último sistema del nivel supera la validación. Es el resultado principal de un ejercicio de Nivel 3.
Tasa de éxito en la verificación
Porcentaje de elementos restaurados que superaron la validación en el primer intento. Cualquier valor por debajo del 100 por ciento es un hallazgo.
Verificación de la inmutabilidad con credenciales no administrativas
La retención de object lock debe probarse, no asumirse. Un operador con una identidad estándar, no administrativa, intenta eliminar o sobrescribir un punto de restauración bloqueado y registra el rechazo. El mismo intento debe realizarse con la propia cuenta de servicio de la aplicación de backup, ya que es la credencial que un atacante tiene más probabilidades de obtener. Si cualquiera de los dos intentos prospera, los backups no están protegidos.
¿Cómo se comparan los tres niveles?
| Nivel de prueba | Alcance | Frecuencia inicial | Métricas clave | Responsable |
|---|---|---|---|---|
| Nivel 1: comprobación puntual | Un archivo, objeto o tabla desde puntos de backup y antigüedades rotativos | Semanal (nivel 1), mensual (nivel 2), trimestral (nivel 3); automatizada | Tasa de éxito; tiempo de recuperación; rechazo por inmutabilidad registrado | Administrador de backup |
| Nivel 2: restauración de aplicación | Una aplicación con sus dependencias, segmento aislado, validación del responsable | Trimestral (nivel 1), semestral (nivel 2), anual (nivel 3) | Tiempo hasta aplicación validada; tasa de éxito; dependencias ausentes | Administrador de backup con conformidad del responsable de la aplicación |
| Nivel 3: ensayo de restauración masiva | Nivel completo en paralelo en una clean room, ejecutado como escenario con análisis posterior | Anual y tras cambios importantes de infraestructura | Rendimiento sostenido; tiempo hasta el primer sistema utilizable; tiempo hasta el nivel completo | Responsable de infraestructura con seguridad y continuidad de negocio |
¿Cómo deberían registrarse los resultados frente al RTO y el RPO?
Cada simulacro debería producir un breve registro que una persona no especialista pueda leer seis meses después: fecha, escenario, sistemas incluidos, el punto de restauración seleccionado y su antigüedad (el RPO alcanzado en esa prueba), los tiempos transcurridos indicados más arriba (el RTO alcanzado), la tasa de éxito, el resultado de la comprobación de inmutabilidad y cada hallazgo con un responsable y una fecha límite.
La comparación útil es la de lo alcanzado frente a lo acordado. Una aplicación de nivel 1 con un RTO de 4 horas que tardó 7 horas en validarse es una brecha documentada: o cambia el RTO, o cambia la infraestructura, o el negocio acepta el riesgo por escrito. El seguimiento de los resultados a lo largo de sucesivos simulacros también muestra si el rendimiento de restauración sigue el ritmo del crecimiento de los datos; el artículo anterior sobre dimensionamiento del repositorio de backup cubre la vertiente de capacidad.
¿Por qué fallan los simulacros de restauración?
La restauración técnica de los datos raramente es la parte que falla. Las causas recurrentes son:
- Dependencias ausentes: un servidor de licencias, una autoridad de certificación, una cola de mensajes o un almacén de configuración quedaron fuera del alcance.
- Identidad: los servicios de directorio no se restauraron primero, o se restauraron con relaciones de confianza que ya no se resuelven.
- Red: los segmentos aislados carecen de DNS, NTP, rutas hacia el destino de backup o reglas de cortafuegos para el tráfico de restauración. Un simple desfase horario puede bloquear los inicios de sesión en el dominio.
- Ruta de restauración infradimensionada: el destino de backup, la red o los hosts de recuperación no pueden sostener el rendimiento de una restauración masiva.
- Credenciales y runbooks almacenados dentro del entorno que se está recuperando.
- Puntos de restauración que nunca fueron inmutables: la retención se configuró en la aplicación pero no la aplicaba el almacenamiento, de modo que la copia de la que dependía el plan ha desaparecido.
Cómo apoya Scality ARTESCA las pruebas de recuperación
Scality ARTESCA es almacenamiento de objetos S3 diseñado como destino de backup, con inmutabilidad S3 Object Lock aplicada por el almacenamiento y no por la aplicación de backup. Dado que las copias inmutables están en línea, y no en soportes extraíbles ni en una cámara fuera de línea, pueden seleccionarse como puntos de restauración y leerse directamente a través de la aplicación de backup, lo que convierte las pruebas de Nivel 1 y Nivel 2 contra copias protegidas en una operación rutinaria.
ARTESCA está validado con las principales aplicaciones de backup, de modo que los simulacros utilizan la misma consola, el mismo catálogo y los mismos flujos de trabajo que los operadores ya conocen. La comprobación de inmutabilidad descrita más arriba puede realizarse como un simple intento de borrado S3 contra un objeto bloqueado, registrando el rechazo como evidencia. La página de seguridad y ciberresiliencia describe los controles con más detalle.
La conclusión práctica: programe la primera restauración de Nivel 2 este trimestre, mida las cinco cifras y deje por escrito la brecha entre lo que se alcanzó y lo que se prometió.