DR responde a la pérdida de una región o sitio completo. El AZ-305 evalúa cuándo usar Azure Site Recovery (replicación de VMs), cuándo basta backup geo-redundante, y cómo se diseña DR para servicios PaaS — que NO usan ASR.
Contenido
ASR replica VMs de forma continua a otra región (o de on-premises a Azure) y orquesta el failover. A diferencia del backup (puntos discretos, RPO de horas), ASR mantiene una réplica casi al día: RPO típico de ~minutos (replicación continua para Azure VMs), RTO típico de minutos.
Backup ≠ DR: backup protege DATOS contra corrupción/borrado con retención histórica; ASR protege la DISPONIBILIDAD del workload con réplica actual. Una estrategia completa suele llevar ambos.
Conceptos clave
Límites a recordar
| Origen → Destino | Componentes | Uso |
|---|---|---|
| Azure VM → otra región | Solo habilitar replicación (agente de extensión) | DR regional de IaaS — el escenario más común |
| Azure VM → zona (zone-to-zone) | Igual, dentro de la región | DR zonal cuando los datos no pueden salir de la región |
| VMware → Azure | Appliance de replicación ASR on-prem | DR de datacenter VMware hacia Azure (y migraciones) |
| Hyper-V → Azure | Provider en el host Hyper-V (+ VMM opcional) | DR de Hyper-V hacia Azure |
| Físico → Azure | Appliance (proceso tipo VMware) | Servidores físicos hacia Azure |
Recovery plans
Test failover (DR drill)
| Servicio | Mecanismo de DR |
|---|---|
| SQL Database / MI | Failover groups (endpoint que no cambia) / active geo-replication |
| Cosmos DB | Réplicas multi-región + service-managed failover (o multi-write) |
| Storage | GRS/GZRS + customer-initiated failover (RA-* para leer sin failover) |
| App Service | Desplegar en 2 regiones + Front Door (no hay réplica nativa) |
| AKS | Clusters en 2 regiones + GitOps/IaC + registro geo-replicado (ACR Premium) |
| Key Vault | Réplica automática a la región emparejada (gestionada por Microsoft) |
| Event Hubs / Service Bus | Geo-disaster recovery (alias de namespace; replica METADATOS, no mensajes) / geo-replication (Premium) |
Trampa de examen
Si la pregunta pide DR de App Service o SQL Database y una opción dice "Azure Site Recovery" — es incorrecta. ASR solo replica VMs. PaaS usa sus mecanismos nativos + IaC para recrear la capa de aplicación.
🛡️Árbol de decisión — Estrategia de DR
Backup+IaC · ASR · Hot Standby · Activo-Activo
Pregunta 1
¿El workload que proteger es IaaS (VMs) o PaaS (SQL DB, App Service, AKS, Cosmos)?
💡 IaaS usa Azure Site Recovery (ASR) para replicar VMs. PaaS usa sus mecanismos nativos — ASR no replica servicios PaaS. Esta es la trampa más común del examen.
| Estrategia | RTO / RPO típico | Costo |
|---|---|---|
| Backup GRS + redeploy con IaC | RTO horas / RPO horas-día | $ |
| ASR (warm standby de VMs) | RTO minutos / RPO minutos | $$ |
| Hot standby (infra desplegada + replicación nativa de datos) | RTO minutos / RPO segundos-minutos | $$$ |
| Activo-activo multi-región | RTO ≈ 0 / RPO ≈ 0 | $$$$ |
| Requisito | Diseño |
|---|---|
| VMs con RTO/RPO de minutos en otra región | Azure Site Recovery |
| Los datos no pueden salir de la región pero piden DR de VMs | ASR zone-to-zone |
| Failover ordenado: DB → app → web con scripts | Recovery plan + Automation runbooks |
| Probar DR sin afectar producción | Test failover en red aislada |
| DR de SQL Database con connection string estable | Failover group (no ASR) |
| DR de App Service multi-región | 2 despliegues + Front Door (no ASR) |
| RTO de horas aceptable, presupuesto mínimo | Backup GRS + CRR + redeploy IaC |
| Migrar VMware a Azure de paso | ASR (o Azure Migrate, que lo usa por debajo) |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una app de 3 capas corre en 12 Azure VMs en North Europe. Requisitos de DR: RTO de 30 minutos, RPO de 5 minutos, failover orquestado en orden (SQL primero, luego app, luego web) con reconfiguración automática de DNS, y simulacros trimestrales sin tocar producción. ¿Qué diseñas?
Inicia sesión para llevar tu progreso.