Disaster Recovery Strategy for SAP

HA vs DR — different problems, different solutions

🛡️ Lars draws a line on the whiteboard. “We have spent three modules on high availability — protecting against component failures within a region. Now Dr. Schmidt asks: what if the entire Azure region goes down? An earthquake, a massive outage, a datacenter fire. HA within the region will not help.”

☁️ Mei nods seriously. “That is disaster recovery territory. DR is about surviving a regional catastrophe by having your systems ready to run in a completely different Azure region. The trade-offs are different — we are balancing recovery speed, data loss tolerance, and cost.”

RPO and RTO

These two metrics drive every DR design decision:

RPO (Recovery Point Objective) — the maximum acceptable amount of data loss, measured in time. An RPO of 15 minutes means you can afford to lose the last 15 minutes of transactions. RPO determines your replication strategy.

RTO (Recovery Time Objective) — the maximum acceptable downtime before the system is operational again. An RTO of 4 hours means the DR system must be serving users within 4 hours of a disaster. RTO determines how “warm” your DR environment needs to be.

🛡️ Lars consults Dr. Schmidt’s requirements. “GlobalPharma needs RPO of 15 minutes for ERP and RTO of 4 hours. For non-production, RPO of 24 hours and RTO of 24 hours are acceptable.”

DR approaches for SAP on Azure

DR approaches for SAP on Azure

Approach	RPO	RTO	Cost	Best for
HSR async (cross-region)	Minutes (near-zero lag)	2-10 minutes (if pre-started)	High — full VM running in DR region	HANA database with strict RPO
Azure Site Recovery (ASR)	5-15 minutes	Minutes to 1 hour	Low — replicated disks, no running VMs	Application servers, ASCS
Backup-based (GRS vault)	Hours (last backup interval)	Hours (restore + start)	Very low — only storage costs	Non-production, dev/test
ANF cross-region replication	RPO depends on replication schedule	Minutes to hours	Medium — replicated volumes	HANA shared and data volumes

📐 Architecture diagram: Open the SAP Cross-Region DR diagram in Excalidraw to see the primary + DR region layout with HSR async and ASR replication flows.

HSR async for HANA DR

For the HANA database, asynchronous HSR to a DR region is the gold standard for low RPO:

• Replication runs continuously in the background
• The secondary in the DR region is a few seconds to minutes behind
• Can be combined with HA HSR (3-node topology: primary, HA secondary, DR tertiary)
• The DR secondary can be a smaller VM that is scaled up during an actual disaster

Azure Site Recovery (ASR) for application tier

ASR replicates VM disks to the DR region continuously:

• Application servers, ASCS VMs, and Web Dispatchers are excellent candidates
• ASR captures disk writes and replicates to the DR region (RPO 5-15 minutes)
• During disaster, ASR creates VMs from the replicated disks
• Recovery plans define the startup order (HANA first, then ASCS, then app servers)
• No running VMs in the DR region until failover — very cost-effective

Backup-based DR

For non-production systems or systems with relaxed RTOs:

• Azure Backup with geo-redundant vaults stores backups in a paired region
• During disaster, restore VMs and databases from backup
• RPO equals the last backup interval (could be hours)
• RTO is hours (restore time + system startup)
• The most cost-effective approach but slowest recovery

Choosing DR per tier

A common pattern is to use different DR approaches for different tiers:

• HANA database: HSR async to DR region (lowest RPO, fastest RTO)
• ASCS/SCS: ASR with recovery plan (moderate RPO, fast RTO)
• Application servers: ASR or rebuild from automation (moderate RPO, moderate RTO)
• Non-production systems: Backup-based recovery only (high RPO, high RTO, lowest cost)

💡 Exam tip: Mixed DR strategies

The exam loves scenarios where you need to choose different DR approaches for different tiers based on RPO/RTO requirements and cost constraints. The answer is almost always a mix: HSR async for HANA, ASR for the app tier, and backup-based for non-prod. Pure backup-based for everything is too slow for production HANA. Pure HSR for everything is too expensive for app servers.

Azure paired regions

Azure paired regions are geographically separated datacenter pairs designed for DR:

• Region pairs are at least 300 miles apart
• Platform updates roll through pairs sequentially (never both at once)
• Data residency is maintained within the same geography
• Some Azure services (GRS, ASR) replicate to the paired region by default

For SAP DR, always design your DR region to be the paired region of your primary region unless regulatory requirements dictate otherwise.

Cost considerations

DR infrastructure can be expensive. Strategies to reduce cost:

• Do not run DR VMs until needed — use ASR instead of running idle VMs
• Right-size DR VMs — the DR HANA VM can be smaller, scaled up during disaster declaration
• Reserved Instances do not apply to DR VMs — unless you run them continuously
• Non-production systems do not need hot DR — backup-based recovery is sufficient
• Regular DR testing is a cost event — plan for it in the budget

Question

What is the difference between RPO and RTO?

Click or press Enter to reveal answer

Answer

RPO (Recovery Point Objective) is the maximum acceptable data loss measured in time — how far back you might lose data. RTO (Recovery Time Objective) is the maximum acceptable downtime — how quickly the system must be operational. RPO drives replication strategy. RTO drives how warm the DR environment needs to be.

Click to flip back

Question

What DR approach is recommended for the HANA database tier?

Click or press Enter to reveal answer

Answer

HSR asynchronous replication to a DR region. It provides near-zero RPO (minutes of lag) and fast RTO (2-10 minutes if the secondary is pre-started). It can be combined with HA HSR in a 3-node topology.

Click to flip back

Question

How does Azure Site Recovery (ASR) work for SAP DR?

Click or press Enter to reveal answer

Answer

ASR continuously replicates VM disks to the DR region with 5-15 minute RPO. No VMs run in the DR region until failover is triggered. During disaster, ASR creates VMs from replicated disks. Recovery plans define startup order (DB first, then ASCS, then app servers). Very cost-effective for application servers.

Click to flip back

Question

Why is backup-based DR appropriate for non-production SAP systems?

Click or press Enter to reveal answer

Answer

Non-production systems have relaxed RPO/RTO requirements (hours to days). Backup-based DR using geo-redundant vaults is the cheapest option — no running VMs, no continuous replication. Restore from backup during disaster. The trade-off is slow recovery time and potential data loss equal to the backup interval.

Click to flip back

Knowledge check

Knowledge Check

GlobalPharma needs RPO of 15 minutes for their production HANA database in DR. Which approach should Lars implement?

AAzure Backup with GRS vault and 6-hour backup scheduleBHSR asynchronous replication to the paired Azure regionCAzure Site Recovery for the HANA VM disksDDaily database export to Azure Blob Storage in the DR region

Check Answer

Knowledge Check

Lars wants to minimize DR costs for SAP application servers while maintaining an RTO of 1 hour. What should he use?

ARun duplicate application server VMs in the DR region at all timesBAzure Site Recovery with recovery plans for ordered startupCManual VM creation from ARM templates during disasterDHANA System Replication for the application tier

Check Answer

Knowledge Check

What is the recommended DR approach for PrecisionSteel's non-production SAP development system?

AHSR async with a dedicated DR VM for the dev systemBAzure Site Recovery with 5-minute RPO replicationCBackup-based recovery from a geo-redundant vaultDNo DR — non-production systems do not need protection

Check Answer

Summary

You now understand DR strategy for SAP on Azure: RPO drives replication choices, RTO drives standby readiness, and cost drives how much infrastructure you maintain in the DR region. HSR async for HANA, ASR for application servers, and backup-based for non-prod is the standard pattern. Azure paired regions provide the geographic separation.

Next, we implement these strategies: setting up HANA multi-tier replication, configuring ASR recovery plans, and testing DR procedures.

🎬 Video coming soon