AZ-104
Deep Dive
A DR strategy defines how to recover critical systems when a disaster occurs. AZ-104 evaluates DR fundamentals, the options in Azure (paired regions, zones, ASR, backup) and how to design a strategy aligned with RTO and RPO objectives.
Contents
Disaster Recovery (DR) is the process of restoring operations after a catastrophic event — datacenter failure, natural disaster, cyberattack or massive human error. A DR strategy defines which systems to protect, how, and with what time and data-loss objectives.
RTO — Recovery Time Objective
The maximum acceptable system downtime. "We must be operational in under 4 hours." Defines how long the business can tolerate the outage.
RTO = 2h: the system must be restored within 2 hours of the disaster.
RPO — Recovery Point Objective
The maximum tolerable data loss in time. "We can't lose more than 1 hour of transactions." Defines the required backup/replication frequency.
RPO = 30min: the most recent backup must be at most 30 minutes old.
Availability SLA
The percentage of time the system must be available. Determines the allowed downtime per year.
99.99% = max 52 min/year | 99.9% = max 8.7h/year | 99% = max 87.6h/year
| Pattern | Description | RTO | RPO | Cost | Azure implementation |
|---|---|---|---|---|---|
| Backup & Restore | Only periodic backups. Restore from scratch in case of disaster. | Hours–days | Hours | Low | Azure Backup only |
| Pilot Light | Minimal infrastructure in DR (only replicated DB). The rest is provisioned during failover. | 30min–2h | Minutes | Low-Medium | ASR for DB + IaC for the rest |
| Warm Standby | Full infrastructure in DR but with reduced capacity (scale up on failover). | Minutes | Seconds–min | Medium-High | ASR + Traffic Manager + VMSS |
| Hot Standby / Active-Active | Full infrastructure in DR receiving active traffic. Transparent failover. | Seconds | 0 or ~0 | High (2x infra) | Multi-region with Front Door/TM + active DB sync |
The inverse RTO/RPO vs Cost relationship
Lower RTO and RPO always cost more — they require more infrastructure and continuous replication. DR design is a balance between the cost of implementing protection vs. the cost of downtime/data loss to the business. For an online store losing $10,000/minute, a hot standby pays for itself.
Azure Backup (Restore)
For: Backup & Restore pattern
Advantages
Very low cost, simple configuration, GRS for cross-region redundancy.
Limitations
High RTO (hours to restore), RPO = backup frequency (hours).
Azure Site Recovery
For: Pilot Light / Warm Standby pattern
Advantages
RPO down to 30 sec, RTO of minutes, always up-to-date replica, test failover.
Limitations
Cost of replication + replica storage, not active-active.
Multi-region active-active
For: Hot Standby / Active-Active pattern
Advantages
RTO ~0 (Traffic Manager/Front Door redirects automatically), RPO ~0 with DB sync.
Limitations
Cost ~2x (full infrastructure in two regions), DB sync complexity.
Availability Zones
For: High availability (not cross-region DR)
Advantages
SLA 99.99%, no additional management, VMs in different physical zones of the region.
Limitations
Does not protect against a full region failure, only within the same region.
Paired regions (Region Pairs)
Azure organizes regions in pairs — each region is paired with another in the same geography (e.g.: East US ↔ West US). Paired regions have special benefits for DR.
Availability Zones (AZ) vs Paired regions
Availability Zones
3 physically separated zones within a region. Protect against a datacenter (zone) failure within the region. SLA 99.99%. Low latency between zones.
Do NOT protect if the entire region goes down (fire, regional natural event).
Paired regions
Regions in the same geography but separated by 300+ miles. Protect against regional disasters. Higher latency between pairs. Requires explicit replication configuration.
Combined strategy
AZ for HA within a region (zone fails) + Paired region for DR (entire region goes down). Maximum resilience.
Plan components
Inventory of critical systems
Classify systems by criticality: critical (RTO < 1h), important (RTO < 8h), non-critical (RTO days). Not everything needs the same level of protection.
RTO and RPO per system
Define concrete objectives agreed with the business. Document the economic justification.
Failover runbooks
Documented step-by-step procedures to execute the failover. Must be executable under pressure, without the lead expert present.
Communication tree
Who notifies whom during the incident. Vendor contacts (Microsoft Support, ISPs). Communication to users/customers.
Critical dependencies to document
An untested DR plan is not a plan — it's a hope. Regular testing is the only way to validate that the plan works, that the RTO/RPO targets are achievable, and that the team knows what to do under pressure.
Test Failover (ASR)
Recommended frequency: Every 3-6 months
Run Test Failover in ASR in an isolated VNet. Verify the VMs boot, the application works and the data is consistent. No impact on production.
Restore drill
Recommended frequency: Annual
Restore a backup in a test environment and verify the application works correctly. Measure the actual restore time vs. the target RTO.
Full DR exercise
Recommended frequency: Annual
Full drill: execute the DR plan as if it were real (without notifying the operations team in advance if possible). Includes communications, decisions and failback.
Common DR mistakes
→ Outdated plan: the infrastructure changed but the plan didn't
→ Only the architect knows how to execute the failover
→ DNS with high TTL (hours of propagation on failover)
→ Never tested: the first "test" is the real disaster
→ Backup exists but the restore has never been tested
→ The paired region doesn't have pre-provisioned resources
Did you get this topic?
Test what you just learned
A company defines an RPO of 15 minutes for its production SQL database. Which Azure solution can achieve this objective?
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.