Una estrategia de DR define cómo recuperar sistemas críticos cuando ocurre un desastre. El AZ-104 evalúa los fundamentos de DR, las opciones en Azure (regiones paired, zonas, ASR, backup) y cómo diseñar una estrategia acorde con los objetivos de RTO y RPO.
Contenido
Disaster Recovery (DR) es el proceso de restaurar operaciones después de un evento catastrófico — fallo de datacenter, desastre natural, ciberataque o error humano masivo. Una estrategia de DR define qué sistemas proteger, cómo y con qué objetivos de tiempo y pérdida de datos.
RTO — Recovery Time Objective
Tiempo máximo aceptable de inactividad del sistema. "Debemos estar operativos en menos de 4 horas". Define cuánto tiempo puede tolerar el negocio sin el servicio.
RTO = 2h: el sistema debe estar restaurado en menos de 2 horas tras el desastre.
RPO — Recovery Point Objective
Pérdida máxima de datos tolerable en tiempo. "No podemos perder más de 1 hora de transacciones". Define la frecuencia de backup/replicación necesaria.
RPO = 30min: el backup más reciente debe tener máximo 30 minutos de antigüedad.
SLA de disponibilidad
Porcentaje de tiempo que el sistema debe estar disponible. Determina el tiempo de downtime permitido anualmente.
99.99% = máx 52 min/año | 99.9% = máx 8.7h/año | 99% = máx 87.6h/año
| Patrón | Descripción | RTO | RPO | Costo | Implementación Azure |
|---|---|---|---|---|---|
| Backup & Restore | Solo backups periódicos. Restaurar desde cero en caso de desastre. | Horas–días | Horas | Bajo | Azure Backup solo |
| Pilot Light | Infraestructura mínima en DR (solo DB replicado). Resto se aprovisiona al hacer failover. | 30min–2h | Minutos | Bajo-Medio | ASR para DB + IaC para resto |
| Warm Standby | Infraestructura completa en DR pero con capacidad reducida (scale up en failover). | Minutos | Segundos–min | Medio-Alto | ASR + Traffic Manager + VMSS |
| Hot Standby / Active-Active | Infraestructura completa en DR recibiendo tráfico activo. Failover transparente. | Segundos | 0 o ~0 | Alto (2x infra) | Multi-región con Front Door/TM + DB sync activo |
La relación inversa RTO/RPO vs Costo
RTO y RPO más bajos siempre cuestan más — requieren más infraestructura y replicación continua. El diseño de DR es un balance entre el costo de implementar la protección vs. el costo del downtime/pérdida de datos para el negocio. Para una tienda online que pierde $10.000/minuto, un hot standby se paga solo.
Azure Backup (Restore)
Para: Backup & Restore pattern
Ventajas
Costo muy bajo, configuración sencilla, GRS para redundancia cross-region.
Limitaciones
RTO alto (horas de restauración), RPO = frecuencia de backup (horas).
Azure Site Recovery
Para: Pilot Light / Warm Standby pattern
Ventajas
RPO hasta 30 seg, RTO de minutos, réplica siempre actualizada, test failover.
Limitaciones
Costo de replicación + almacenamiento de réplica, no es activo-activo.
Multi-región activo-activo
Para: Hot Standby / Active-Active pattern
Ventajas
RTO ~0 (Traffic Manager/Front Door redirige automáticamente), RPO ~0 con DB sync.
Limitaciones
Costo ~2x (infraestructura completa en dos regiones), complejidad de sync de DB.
Availability Zones
Para: Alta disponibilidad (no DR inter-regional)
Ventajas
SLA 99.99%, sin gestión adicional, VMs en distintas zonas físicas de la región.
Limitaciones
No protege contra fallo de región completa, solo dentro de la misma región.
Regiones paired (Region Pairs)
Azure organiza las regiones en pares — cada región está emparejada con otra en la misma geografía (ej: East US ↔ West US). Las regiones paired tienen beneficios especiales para DR.
Availability Zones (AZ) vs Regiones paired
Availability Zones
3 zonas físicamente separadas dentro de una región. Protegen ante fallo de datacenter (zona) dentro de la región. SLA 99.99%. Baja latencia entre zonas.
NO protegen si la región completa cae (incendio, evento natural regional).
Regiones paired
Regiones en la misma geografía pero separadas 300+ millas. Protegen ante desastres regionales. Mayor latencia entre pares. Requiere configuración explícita de replicación.
Estrategia combinada
AZ para HA dentro de región (zona falla) + Región paired para DR (región completa cae). Máxima resiliencia.
Componentes del plan
Inventario de sistemas críticos
Clasificar sistemas por criticidad: críticos (RTO < 1h), importantes (RTO < 8h), no críticos (RTO días). No todo necesita el mismo nivel de protección.
RTO y RPO por sistema
Definir objetivos concretos acordados con el negocio. Documentar la justificación económica.
Runbooks de failover
Procedimientos paso a paso documentados para ejecutar el failover. Deben poderse ejecutar bajo presión, sin el experto principal.
Árbol de comunicación
Quién notifica a quién durante el incidente. Contactos de proveedores (Microsoft Support, ISPs). Comunicación a usuarios/clientes.
Dependencias críticas a documentar
Un plan de DR no probado no es un plan — es una esperanza. El testing regular es la única forma de validar que el plan funciona, que los RTO/RPO son alcanzables y que el equipo sabe qué hacer bajo presión.
Test Failover (ASR)
Frecuencia recomendada: Cada 3-6 meses
Ejecutar Test Failover en ASR en VNet aislada. Verificar que las VMs arrancan, la aplicación funciona y los datos son consistentes. Sin impacto en producción.
Restore drill
Frecuencia recomendada: Anual
Restaurar un backup en un entorno de test y verificar que la aplicación funciona correctamente. Medir el tiempo real de restauración vs. el RTO objetivo.
Full DR exercise
Frecuencia recomendada: Anual
Simulacro completo: ejecutar el plan de DR como si fuera real (sin avisarle al equipo de operaciones con anticipación si es posible). Incluye comunicaciones, decisiones y failback.
Errores comunes en DR
→ Plan desactualizado: la infraestructura cambió pero el plan no
→ Solo el arquitecto sabe ejecutar el failover
→ DNS con TTL alto (horas de propagación en failover)
→ Nunca probado: el primer "test" es el desastre real
→ Backup existe pero restore nunca se ha probado
→ Region paired no tiene los recursos pre-aprovisionados
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa define un RPO de 15 minutos para su base de datos SQL en producción. ¿Qué solución en Azure permite alcanzar este objetivo?
Inicia sesión para llevar tu progreso.