AZ-104
Deep Dive
RTO y RPO son los dos métricas fundamentales de DR que definen los objetivos de recuperación. El AZ-104 evalúa su comprensión exacta y la capacidad de elegir la tecnología Azure correcta para alcanzar RTO/RPO específicos.
Contenido
RTO
Recovery Time Objective
Tiempo máximo que puede transcurrir desde que ocurre el desastre hasta que el sistema está completamente operativo. Mide tiempo de inactividad máximo aceptable.
Ejemplo concreto
RTO = 4 horas: si el desastre ocurre a las 09:00, el sistema debe estar operativo antes de las 13:00. Si a las 13:00 aún no funciona, se ha superado el RTO.
↑ RTO alto = más tiempo de inactividad tolerado → solución más barata
↓ RTO bajo = menos tiempo de inactividad tolerado → solución más cara
RPO
Recovery Point Objective
Máxima cantidad de datos (en tiempo) que se puede perder. Determina con qué frecuencia se necesitan backups o replicación. Mide pérdida de datos máxima aceptable.
Ejemplo concreto
RPO = 1 hora: el backup más antiguo que puede ser el punto de restauración tiene máximo 1 hora de antigüedad. Si se hacen backups cada 24h, el RPO real es 24h — incumplimiento del objetivo.
↑ RPO alto = más pérdida de datos tolerada → backup menos frecuente → más barato
↓ RPO bajo = menos pérdida de datos tolerada → replicación continua → más caro
La diferencia visual
Preguntas para definir RTO
Preguntas para definir RPO
SLA de Azure ≠ RTO/RPO de tu sistema
El SLA de 99.99% de una VM en Availability Zones garantiza disponibilidad del servicio de VM, no la recuperación ante un desastre que afecte a toda tu aplicación. Tu RTO/RPO depende de cómo has diseñado la resiliencia de tu sistema, no solo del SLA del recurso individual.
| SLA | Disponibilidad | Downtime/año | Downtime/mes | Ejemplo Azure |
|---|---|---|---|---|
| 99% | 99% | 87.6 horas | 7.3 horas | Sin arquitectura de redundancia específica |
| 99.9% | 99.9% | 8.76 horas | 43.8 minutos | VM sola con Premium SSD |
| 99.95% | 99.95% | 4.38 horas | 21.9 minutos | VM en Availability Set (2+ VMs) |
| 99.99% | 99.99% | 52.6 minutos | 4.4 minutos | VM en Availability Zones, Azure SQL, App Service |
| 99.999% | 99.999% | 5.26 minutos | 26 segundos | Multi-región activo-activo (no un SLA estándar de Azure) |
| Tecnología | RTO típico | RPO típico | Cuándo usar |
|---|---|---|---|
| Azure Backup (VM daily) | 2-8 horas | 24 horas | Sistemas no críticos, datos que cambian poco, bajo presupuesto |
| Azure Backup (Enhanced, 4h) | 2-4 horas | 4 horas | Sistemas moderadamente críticos con budget limitado |
| Azure Site Recovery | 15 min - 1 hora | 30 segundos - 5 minutos | VMs críticas que deben recuperarse rápido ante caída de región |
| Azure SQL Active Geo-Replication | 5-30 segundos | 5 segundos o menos | Base de datos SQL que necesita DR con mínima pérdida de datos |
| Azure SQL Failover Groups | < 30 segundos (auto) | 5 segundos | SQL DB con failover automático y transparente para la app |
| Storage GRS + Cross-Region Restore | Horas (restore manual) | ~15 minutos de lag de replicación | Datos de blob que necesitan redundancia pero sin RTO agresivo |
| Multi-región activo-activo | 0-30 segundos | ~0 | Apps críticas con SLA muy alto, failover transparente requerido |
| Availability Zones | < 1 segundo (automático) | 0 | HA dentro de región — zona de datacenter falla, no región completa |
MTTR — Mean Time To Recovery
Tiempo promedio que tarda en recuperarse el sistema después de un fallo. Mide la eficiencia del proceso de recuperación. MTTR ≤ RTO = cumplimiento del objetivo.
MTTR = Σ(Tiempo de inactividad) / Número de incidentes
MTBF — Mean Time Between Failures
Tiempo promedio entre fallos del sistema. Mide la confiabilidad. Mayor MTBF = sistema más fiable. Se usa para calcular la disponibilidad.
MTBF = Σ(Tiempo operativo) / Número de fallos
Availability = MTBF / (MTBF + MTTR)
Porcentaje de tiempo que el sistema está disponible. Derivado de MTBF y MTTR. Para mejorar la disponibilidad: aumentar MTBF (menos fallos) o reducir MTTR (recuperación más rápida).
Disponibilidad = MTBF / (MTBF + MTTR) × 100%
MTTD — Mean Time To Detect
Tiempo promedio desde que ocurre el fallo hasta que se detecta. Reducir MTTD con alertas y monitoreo proactivo en Azure Monitor.
MTTD se reduce con: alertas de métricas, health probes, Application Insights
Escenario 1
"La empresa no puede tolerar más de 30 minutos de pérdida de datos de su base de datos SQL. ¿Qué servicio usar?"
Razonamiento
RPO = 30 min. Azure SQL tiene backup automático de logs de transacciones cada 5-15 minutos (RPO real ≈ 15 min). Para DR cross-región: Active Geo-Replication con RPO < 5 segundos. El backup básico diario da RPO de 24h — no cumple.
Respuesta correcta
Azure SQL Active Geo-Replication o Failover Groups
Escenario 2
"Necesitamos que las VMs se recuperen en menos de 2 horas si hay un desastre que afecta a toda la región East US."
Razonamiento
RTO = 2h, desastre de región completa. Azure Backup tardaría horas-días en restaurar. Azure Site Recovery replica las VMs a otra región y permite failover en minutos (RTO 15-60 min). Es la solución correcta para este RTO.
Respuesta correcta
Azure Site Recovery replicando VMs a West US
Escenario 3
"El SLA del negocio exige 99.99% de disponibilidad. La aplicación corre en una sola VM con Premium SSD. ¿Se cumple el objetivo?"
Razonamiento
Una sola VM con Premium SSD tiene SLA de 99.9% de Azure = hasta 8.76 horas de downtime/año. 99.99% = máx 52 minutos/año. Para 99.99%, necesita VMs en Availability Zones (zonas distintas) o una arquitectura multi-región.
Respuesta correcta
No. Necesita VMs en 2+ Availability Zones o Availability Set.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa tiene un RTO de 1 hora y un RPO de 15 minutos para sus VMs críticas en Azure. Un desastre afecta la región completa a las 14:00. El último backup fue a las 12:00. ¿Cuál de las siguientes afirmaciones es correcta?