RTO y RPO son el lenguaje en que el negocio expresa cuánta interrupción y cuánta pérdida de datos tolera. El AZ-305 te dará números ("RTO 1 hora, RPO 5 minutos") y esperará que los traduzcas a la tecnología más barata que los cumpla.
Contenido
RTO — Recovery Time Objective
¿CUÁNTO TIEMPO puede estar caído el servicio?
RPO — Recovery Point Objective
¿CUÁNTOS DATOS (en tiempo) se pueden perder?
MTTR / MTBF
MTTR (Mean Time To Recover): promedio real de recuperación — debe ser ≤ RTO. MTBF (Mean Time Between Failures): frecuencia esperada de fallos — alimenta el diseño de redundancia.
Trampa conceptual
Replicación geo asíncrona (GRS, geo-replication, ASR) nunca da RPO 0 — siempre hay segundos/minutos en vuelo. Si piden RPO 0 entre regiones lejanas, no existe: hay que renegociar el requisito o aceptar escritura síncrona con la latencia que implica (zonas sí lo permiten).
⏱️Espectro RTO / RPO — estrategias de DR
Selecciona un tier para ver tecnologías y tip de examen
| Objetivos | Estrategia | Tecnologías Azure |
|---|---|---|
| RTO días / RPO 24h | Backup + restore | Azure Backup GRS, geo-restore de SQL |
| RTO horas / RPO 1h | Backup geo + redeploy IaC (cold standby) | Backup + CRR, Bicep/Terraform, geo-restore |
| RTO ~1h / RPO minutos | Warm standby con replicación | ASR para VMs, read replicas |
| RTO minutos / RPO segundos | Hot standby + replicación nativa | SQL failover groups, Cosmos multi-región, App Service x2 + Front Door |
| RTO ≈0 / RPO ≈0 | Activo-activo | Front Door + regiones activas + Cosmos multi-write; RPO 0 real solo con sincronía (zonas) |
Reducir RTO/RPO encarece exponencialmente: pasar de horas a minutos multiplica el costo (réplicas corriendo); de minutos a ~cero lo vuelve a multiplicar (todo duplicado activo). El arquitecto correcto elige la opción más barata que CUMPLE — sobre-diseñar es una respuesta incorrecta en el examen.
Clasificar workloads por criticidad
Costos ocultos a considerar
| La pregunta dice... | Concluye... |
|---|---|
| "Pueden perderse hasta 24h de datos" | RPO 24h → backups diarios bastan |
| "Máximo 15 minutos de datos perdidos" | RPO 15 min → replicación continua o log backups cada 15 min |
| "El servicio debe volver en 1 hora" | RTO 1h → warm standby; restore masivo difícilmente cabe |
| "Sin pérdida de datos" + misma región | RPO 0 → replicación síncrona entre zonas |
| "Sin pérdida de datos" + entre regiones lejanas | Conflicto: replicación geo es asíncrona — replantear requisito |
| "Al menor costo posible" + RTO/RPO holgados | La opción más barata que cumple (backup + IaC), no la más robusta |
| "Probar el plan sin afectar producción" | Test failover / DR drill aislado |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
El negocio define para una app interna de reporting: RTO de 8 horas y RPO de 24 horas, con el menor costo posible. La app corre en 2 VMs con una base de datos SQL en VM. ¿Qué estrategia de DR diseñas?
Inicia sesión para llevar tu progreso.