Pruebas de recuperación ante desastres sin impacto

Un plan de recuperación ante desastres que nunca se ha probado es solo una hipótesis. La experiencia en situaciones reales demuestra que los planes de DR suelen revelar deficiencias —desviaciones de configuración, automatización ausente, runbooks obsoletos o tiempos de inicio superiores a los previstos— que solo salen a la luz en condiciones de prueba. Las pruebas periódicas de DR son la única manera de confiar en que el plan funcionará cuando más lo necesite.

Test Failover es una funcionalidad integrada de Azure Site Recovery que permite simular una conmutación por error a la región secundaria sin interrumpir la producción. Durante una conmutación por error de prueba, ASR crea copias de las VM replicadas en una red virtual aislada de la región secundaria. Las VM de producción siguen funcionando con normalidad en la región primaria, por lo que no existe riesgo para los usuarios activos.

La VNet de prueba aislada no debe tener conectividad con los sistemas de producción. Esto evita que las VM de prueba escriban accidentalmente en la base de datos de producción, envíen correos electrónicos a clientes reales o activen transacciones de pago. Cree una VNet de conmutación por error de prueba dedicada, sin emparejamiento con las VNet de producción y sin acceso a Internet, y úsela exclusivamente para los simulacros de DR.

Una prueba de DR debe validar un conjunto específico de criterios:

• Tiempo de arranque — ¿se inician todas las VM dentro del intervalo previsto?
• Inicio de la aplicación — ¿se inicializa correctamente la aplicación al conectarse a la base de datos recuperada?
• Integridad de los datos — ¿son coherentes y completos los datos del punto de recuperación?
• RTO real — mida el tiempo total transcurrido desde que se activa la conmutación por error hasta que la aplicación empieza a atender solicitudes
• Ejecución del runbook — ¿se completaron correctamente todos los scripts de automatización?

Durante la prueba, inicie un temporizador en el momento en que active la conmutación por error de prueba. Deténgalo cuando se confirme que la aplicación funciona correctamente (el sondeo de estado del equilibrador de carga devuelve 200 OK). Este es su RTO real. Compárelo con el RTO objetivo. Si el valor real supera el objetivo, identifique los cuellos de botella —inicio lento de las VM, inicialización prolongada de la base de datos o retraso en la propagación de DNS— y soluciónelos.

Cuando se complete la conmutación por error de prueba, conéctese a la base de datos recuperada y compruebe los datos. Verifique que estén presentes las transacciones confirmadas antes del límite de replicación y que las transacciones confirmadas parcialmente se gestionen correctamente (se reviertan o se completen). En las bases de datos con restauración a un momento dado (PITR), pruebe a restaurar la base de datos a una marca de tiempo específica y compruebe que el estado de los datos sea el esperado.

Cuando finalice la prueba, debe limpiar los recursos de la conmutación por error de prueba: las VM de prueba, sus discos y las interfaces de red de la región secundaria. Azure Site Recovery proporciona en el portal la acción 'Cleanup test failover', que quita automáticamente todos los recursos de prueba. Si olvida realizar la limpieza, desperdiciará dinero y llenará la región secundaria de recursos obsoletos.

Después de cada prueba de DR, redacte un informe de prueba que incluya: la fecha y el alcance de la prueba, el RTO y el RPO reales obtenidos, una lista de comprobación de los elementos de validación con su estado de aprobado o error, las deficiencias o los errores observados y las acciones correctivas previstas. Este informe es valioso para las auditorías de cumplimiento (ISO 27001, SOC 2, HIPAA) y para realizar un seguimiento de la mejora de la madurez de DR a lo largo del tiempo.

Los procedimientos recomendados del sector y los marcos de cumplimiento suelen exigir pruebas de DR como mínimo anuales, pero muchas organizaciones realizan pruebas trimestrales o incluso mensuales para las cargas de trabajo de nivel 1. Las pruebas más frecuentes detectan antes las desviaciones de configuración y aumentan la confianza y la experiencia práctica del equipo. Automatice tanto como sea posible la configuración y la verificación de las pruebas para reducir el esfuerzo que requieren las pruebas frecuentes.

Azure Chaos Studio es un servicio administrado de ingeniería del caos que permite inyectar errores controlados en recursos de Azure para probar la resiliencia de las aplicaciones. Puede apagar VM, provocar errores de zona, limitar la CPU o inyectar latencia de red para observar el comportamiento de la aplicación. A diferencia de un simulacro de DR estándar, la ingeniería del caos comprueba si la aplicación se degrada correctamente en condiciones de error parcial.

Las pruebas de DR son más valiosas como parte de un ciclo de mejora continua: Planificar → Ejecutar → Medir → Corregir → Repetir. Después de cada prueba, solucione las deficiencias encontradas, actualice los runbooks y la documentación, y vuelva a realizar la prueba. Con el tiempo, la diferencia entre los objetivos de RTO/RPO declarados y los valores reales obtenidos debería reducirse hasta que supere sistemáticamente todas las pruebas dentro del margen de tolerancia.

Ponga a prueba sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) de esta lección.

En esta lección ha aprendido que la conmutación por error de prueba permite simular un evento de DR sin interrumpir la producción mediante la creación de copias de las VM en una VNet aislada; durante la prueba debe medir el RTO real y verificar la integridad de los datos; y después de cada simulacro debe limpiar los recursos de prueba y documentar los resultados. A continuación, exploraremos la recuperación ante desastres específicamente para servicios PaaS como Azure SQL Database.