Choosing a DR Strategy for a Tier-1 SAP Database With a 15-Minute RTO
A manufacturing customer runs SAP ERP Central Component on SQL Server with a 3.1 TB database in the West Europe region. Their business requires an RTO of 15 minutes and an RPO of 5 minutes for the productive database. The infrastructure team proposes using Azure Site Recovery to replicate the database VM to North Europe. The database team objects, arguing that Site Recovery crash-consistent snapshots will not produce a recoverable SQL Server database and that they need native replication. The customer has no existing SQL Server Always On configuration and wants the lowest-cost option that meets the stated objectives.
1. Evaluate the Site Recovery proposal against the stated RTO and RPO, and explain why the database team's objection is or is not correct.
Read the worked answer
The database team is directionally correct, and the Site Recovery proposal does not meet the objectives as described.
Azure Site Recovery replicates at the block level and can produce crash-consistent and, with a guest agent, application-consistent recovery points. For SQL Server, application-consistent points depend on the VSS writer and are taken at a configured frequency, often every few hours. That frequency cannot deliver a 5-minute RPO with confidence; between application-consistent points you are relying on crash consistency, and recovery from a crash-consistent image requires SQL Server to replay the transaction log, which is possible but does not guarantee the 5-minute RPO and lengthens recovery time.
The 15-minute RTO is the harder constraint. A Site Recovery failover involves bringing up the VM in the target region, attaching disks, and then starting SQL Server and letting it recover. For a 3.1 TB database, crash recovery and any log redo can alone exceed 15 minutes, before application servers are validated. Site Recovery is a sound tool for whole-workload regional evacuation, but it is not a mechanism that reliably delivers a 15-minute RTO and 5-minute RPO for a multi-terabyte OLTP database.
The correct pattern is native database replication: SQL Server Always On availability groups with a secondary replica in the secondary region, synchronizing asynchronously with a log send queue that supports the 5-minute RPO. The secondary replica is continuously recovering, so failover is a role change measured in seconds to low minutes, and the RTO is achievable.
2. The customer wants the lowest-cost design that still meets the objectives. Recommend an architecture and identify where cost can be reduced without violating the RTO and RPO.
Read the worked answer
Recommended architecture:
- Primary region: two SQL Server nodes in an Always On availability group, synchronous commit within the region, fronted by an internal load balancer or a distributed network name, with SAP application servers connecting through the listener.
- Secondary region: one asynchronous secondary replica. Asynchronous commit is required because of the inter-region latency; synchronous commit across regions would inflate every commit and is not appropriate for this distance.
- File share witness or cloud witness for quorum. A cloud witness is the cheapest quorum option and avoids maintaining a third VM.
- SAP application servers in the secondary region kept at a minimal footprint, scaled out during an actual failover.
Cost reductions that preserve the objectives:
- Run the secondary-region replica on a smaller VM only if SQL Server can keep up with log redo; otherwise the log send queue grows and the RPO is breached. This must be validated, not assumed.
- Use reserved instances or savings plans for the steady-state primary nodes.
- Deallocate or right-size non-production systems in the secondary region; they are not in the RTO path.
- Do not use Site Recovery as a substitute for the database replica, but Site Recovery can still protect the application tier and other components where a longer RTO is acceptable.
What must not be cut: the secondary replica must be continuously running and receiving log, because a replica that is only started during a disaster cannot meet a 5-minute RPO.