AZ-104
Deep Dive
RTO and RPO are the two fundamental DR metrics that define recovery objectives. AZ-104 evaluates their exact understanding and the ability to choose the right Azure technology to meet specific RTO/RPO targets.
Contents
RTO
Recovery Time Objective
The maximum time that can elapse from when the disaster occurs until the system is fully operational again. Measures maximum acceptable downtime.
Concrete example
RTO = 4 hours: if the disaster happens at 09:00, the system must be operational before 13:00. If it's still down at 13:00, the RTO has been exceeded.
↑ High RTO = more downtime tolerated → cheaper solution
↓ Low RTO = less downtime tolerated → more expensive solution
RPO
Recovery Point Objective
The maximum amount of data (in time) that can be lost. Determines how often backups or replication are needed. Measures maximum acceptable data loss.
Concrete example
RPO = 1 hour: the oldest backup that can serve as the restore point must be at most 1 hour old. If backups run every 24h, the real RPO is 24h — a violation of the objective.
↑ High RPO = more data loss tolerated → less frequent backup → cheaper
↓ Low RPO = less data loss tolerated → continuous replication → more expensive
The visual difference
Questions to define RTO
Questions to define RPO
Azure SLA ≠ your system's RTO/RPO
The 99.99% SLA of a VM in Availability Zones guarantees availability of the VM service, not recovery from a disaster affecting your entire application. Your RTO/RPO depends on how you've designed your system's resilience, not just the individual resource's SLA.
| SLA | Availability | Downtime/year | Downtime/month | Azure example |
|---|---|---|---|---|
| 99% | 99% | 87.6 hours | 7.3 hours | No specific redundancy architecture |
| 99.9% | 99.9% | 8.76 hours | 43.8 minutes | Single VM with Premium SSD |
| 99.95% | 99.95% | 4.38 hours | 21.9 minutes | VM in an Availability Set (2+ VMs) |
| 99.99% | 99.99% | 52.6 minutes | 4.4 minutes | VM in Availability Zones, Azure SQL, App Service |
| 99.999% | 99.999% | 5.26 minutes | 26 seconds | Multi-region active-active (not a standard Azure SLA) |
| Technology | Typical RTO | Typical RPO | When to use |
|---|---|---|---|
| Azure Backup (VM daily) | 2-8 hours | 24 hours | Non-critical systems, slow-changing data, low budget |
| Azure Backup (Enhanced, 4h) | 2-4 hours | 4 hours | Moderately critical systems with limited budget |
| Azure Site Recovery | 15 min - 1 hour | 30 seconds - 5 minutes | Critical VMs that must recover fast after a region outage |
| Azure SQL Active Geo-Replication | 5-30 seconds | 5 seconds or less | SQL database needing DR with minimal data loss |
| Azure SQL Failover Groups | < 30 seconds (auto) | 5 seconds | SQL DB with automatic, app-transparent failover |
| Storage GRS + Cross-Region Restore | Hours (manual restore) | ~15 minutes of replication lag | Blob data needing redundancy without an aggressive RTO |
| Multi-region active-active | 0-30 seconds | ~0 | Critical apps with very high SLA, transparent failover required |
| Availability Zones | < 1 second (automatic) | 0 | HA within a region — datacenter zone fails, not the whole region |
MTTR — Mean Time To Recovery
The average time it takes for the system to recover after a failure. Measures the efficiency of the recovery process. MTTR ≤ RTO = objective met.
MTTR = Σ(Downtime) / Number of incidents
MTBF — Mean Time Between Failures
The average time between system failures. Measures reliability. Higher MTBF = more reliable system. Used to calculate availability.
MTBF = Σ(Uptime) / Number of failures
Availability = MTBF / (MTBF + MTTR)
The percentage of time the system is available. Derived from MTBF and MTTR. To improve availability: increase MTBF (fewer failures) or reduce MTTR (faster recovery).
Availability = MTBF / (MTBF + MTTR) × 100%
MTTD — Mean Time To Detect
The average time from when the failure occurs until it's detected. Reduce MTTD with alerts and proactive monitoring in Azure Monitor.
MTTD is reduced with: metric alerts, health probes, Application Insights
Scenario 1
"The company cannot tolerate more than 30 minutes of data loss for its SQL database. Which service should be used?"
Reasoning
RPO = 30 min. Azure SQL automatically backs up transaction logs every 5-15 minutes (real RPO ≈ 15 min). For cross-region DR: Active Geo-Replication with RPO < 5 seconds. Basic daily backup gives a 24h RPO — does not meet the target.
Correct answer
Azure SQL Active Geo-Replication or Failover Groups
Scenario 2
"We need the VMs to recover in under 2 hours if a disaster affects the entire East US region."
Reasoning
RTO = 2h, full region disaster. Azure Backup would take hours-days to restore. Azure Site Recovery replicates the VMs to another region and allows failover in minutes (RTO 15-60 min). It's the correct solution for this RTO.
Correct answer
Azure Site Recovery replicating VMs to West US
Scenario 3
"The business SLA requires 99.99% availability. The application runs on a single VM with Premium SSD. Is the target met?"
Reasoning
A single VM with Premium SSD has an Azure SLA of 99.9% = up to 8.76 hours of downtime/year. 99.99% = max 52 minutes/year. To reach 99.99%, it needs VMs in Availability Zones (different zones) or a multi-region architecture.
Correct answer
No. It needs VMs across 2+ Availability Zones or an Availability Set.
Did you get this topic?
Test what you just learned
A company has an RTO of 1 hour and an RPO of 15 minutes for its critical VMs in Azure. A disaster affects the entire region at 14:00. The last backup was at 12:00. Which of the following statements is correct?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.