8.2 Azure Site Recovery Architecture for Hybrid Workloads

Why This Topic Matters

Azure Site Recovery (ASR) is Microsoft's flagship disaster recovery orchestration service and the direct answer to the official skill "Recommend a recovery solution for Azure and hybrid workloads that meets recovery objectives" whenever the scenario spans on-premises and Azure together -- the "hybrid" half of that bullet. AZ-305 scenarios frequently describe a company with an on-premises VMware or Hyper-V estate that wants Azure as a DR target, or an Azure region that needs a DR partner region. Confusing ASR (replicates whole machines for orchestrated failover) with Azure Backup (protects point-in-time data) is one of the most common mistakes candidates make, and the exam exploits it directly.

Core Concept: ASR Replicates Machines, Not Just Data

ASR continuously replicates entire virtual machines -- OS disk, data disks, and configuration -- to a target location so the whole machine can be failed over and brought online, rather than restored file-by-file. This makes ASR the tool for recovery time, while Azure Backup (covered in the next section) is the tool for recovery point granularity and long-term retention.

Supported Replication Scenarios

For Azure-to-Azure replication, ASR uses continuous, near-real-time replication -- there is no separate configuration server to deploy, which is why the exam often frames Azure-to-Azure ASR as the simplest hybrid-adjacent DR pattern to recommend when both regions are already Azure.

For VMware/Hyper-V-to-Azure, three roles matter:

• Configuration server -- coordinates replication, manages data flow, and hosts the process server (usually the first component deployed on-premises).
• Process server -- installed alongside or near the configuration server; receives replication traffic, performs caching, compression, and encryption before sending to Azure.
• Master target server -- automatically deployed in Azure; receives replicated data during failback.

Recovery Points, Consistency, and Recovery Plans

ASR keeps a rolling window of recovery points so you can fail over to a point before a corruption event, not just the latest replicated state. Two consistency types matter for the exam:

• Crash-consistent recovery points are captured very frequently (as often as every few minutes) but only guarantee the disk state as if the VM had crashed -- in-flight application transactions may be incomplete.
• App-consistent recovery points additionally quiesce the application (using VSS on Windows) so multi-tier applications like SQL Server come back in a transactionally consistent state. App-consistent snapshots are taken on a configurable interval, commonly defaulting to every few hours (adjustable from 1 to 12 hours), because the quiescing operation has more overhead than a crash-consistent snapshot.

A recovery plan groups multiple VMs (e.g., a web tier, an app tier, and a database tier) into one failover unit with defined boot order and can inject manual or automated (Azure Automation runbook) steps between tiers -- for example, waiting for the database tier to come fully online before starting the app tier.

Test Failover: Non-Disruptive Validation

One of ASR's most exam-relevant features is test failover, which spins up replica VMs in an isolated network without impacting production replication or the live environment. This lets an architect satisfy compliance requirements for periodic DR testing (a recurring theme across this whole chapter) without any customer-facing risk. A scenario asking "how do we validate our DR plan quarterly without disrupting production" is describing test failover almost verbatim.

Failover and Failback

After a real disaster, you perform a failover (planned, with a final data sync, or unplanned, from the last available recovery point) to bring the replica VMs online as the new production. Once the primary site is restored, failback reverses replication direction to resynchronize and cut back over -- ASR supports failback to the original on-premises site or original Azure region without a full re-protection from scratch, provided the original source is still recognized by the vault.

Common Decision Traps

• Recommending Azure Backup when the requirement is "bring the whole application online in another region quickly" -- that is an ASR use case, not a backup use case.
• Recommending ASR when the requirement is "retain 7 years of monthly snapshots for audit" -- that is a backup/long-term-retention use case, not ASR's job (ASR's recovery point window is measured in hours to a few days, not years).
• Assuming crash-consistent recovery points are always sufficient for databases; app-consistent points are needed when transactional integrity at failover time is a stated requirement.
• Forgetting that a recovery plan's boot order and automation steps are what actually make a multi-tier failover meet a stated RTO -- a bare VM-by-VM failover with no orchestration will be slower and less predictable.

Exam Scenario

A company runs a three-tier application on VMware on-premises and wants an Azure-based DR site with an RTO under 2 hours and the ability to test the DR plan every quarter without impacting production. The correct recommendation: deploy a configuration server and process server on-premises, enable ASR replication for all VMware VMs to the target Azure region, group the tiers into a recovery plan with the correct boot order, and use test failover for the quarterly validation requirement.