In a lot of Azure projects, someone eventually asks me how to run disaster recovery (DR) drills for Azure virtual machines that actually mean something, without putting production at risk or drowning in complexity. Azure Site Recovery handles the replication of Azure VMs to a secondary region well. The harder part in practice is validating your recovery plans on a regular basis without causing more problems than you fix. If your last test failover was months ago, you're not ready for the next audit.

Azure Site Recovery replicates Azure VMs continuously to a second region

Azure Site Recovery (ASR) continuously replicates running Azure VMs to a secondary Azure region. That gives you a consistent DR foundation, which is less common in the cloud than people assume. Replication happens at block level and close to real time, so RPOs usually land somewhere between a few seconds and a few minutes. Everything is configured in the Recovery Services vault: source VMs, target region, networks, replication policies and retention. Azure Backup is about restoring files or snapshots. ASR is about bringing whole workloads back quickly and in a controlled order at a secondary site, including network, DNS and identity.

Recovery plans give you control over the failover sequence

For complex workloads, recovery plans do most of the heavy lifting in Azure Site Recovery. You define exactly how the failover runs. VMs can be grouped and started in a set order, and you can insert automation such as Azure Automation Runbooks or manual steps like DNS changes or checklist confirmations. Once there are dependencies involved (SQL behind a web tier, or line-of-business apps that rely on AD), you need that orchestration. You create recovery plans in the Recovery Services vault and add scripted or manual steps wherever you need them. Every action gets logged, so the plan effectively doubles as a runbook, which helps a lot once auditors start asking questions.

Test failover runs the drill in an isolated virtual network

The feature I value most in ASR is test failover. You can run a full recovery drill whenever you like by starting one or more replicated VMs in an isolated, non-production subnet, usually a dedicated test VNet. Production VMs, users and applications aren't affected. That means you can test application stacks, identity dependencies such as Active Directory, DNS resolution and network routing end to end. The drill flow I've found most practical looks like this:

flowchart TD
    Preparation["Preparation: Define recovery plan"]
    Replication["Replication: VMs to target region"]
    TestFailover["Test failover: Boot VMs in test VNet"]
    Validation["Validation: Test apps & dependencies"]
    Cleanup["Cleanup: Remove test resources"]
    Preparation --> Replication --> TestFailover --> Validation --> Cleanup

Figure: A typical DR drill with Azure Site Recovery

After every test, run the built-in cleanup ("Cleanup test failover"). It removes leftover resources so you don't keep paying for them.

Network, DNS and identity cause most failed drills

In my experience, DR drills rarely fail because of VM replication. They fail because someone overlooked a dependency in the network, DNS or identity design. Run a test failover without a domain controller in the target VNet and the VMs will start, but they can't reach the domain, and important applications break. Your recovery plan should always include steps to start (or temporarily deploy) DCs, DNS forwarders and every network configuration the test network needs. For a real production failover, you need a clear plan for updating public IPs, NSGs and route tables in the target VNet. If Application Gateways or complicated public endpoints are part of the setup, test and document them carefully, because you'll often have to make manual adjustments.

Practical tip: Build a reusable test VNet with dedicated subnets for DR exercises instead of cloning production. You'll make far fewer mistakes and spend much less time cleaning up.

Drill frequency, RPO/RTO and documentation decide what you can show auditors

A DR plan is worth exactly as much as your last successful drill. For critical workloads I recommend at least one drill per year, with every step, screenshot and result documented. The Recovery Services vault logs failover and cleanup actions on its own, but you should also keep your own record of the validation tests for each drill (apps, identity, DNS). ASR's RPO (Recovery Point Objective) is typically a few seconds to a few minutes, depending on workload activity and replication settings. The RTO (Recovery Time Objective) depends mostly on how well automated and documented your network and identity failover processes are. Regular full-scale drills show you the weak spots early, and they give you something concrete to put in front of auditors.

Azure Site Recovery only pays off with recurring drills

Azure Site Recovery is not just another backup product. For real-world high availability and DR in Azure, I consider it essential. Whether it works for you has less to do with the technical setup and more to do with solid recovery plans, tested procedures for network and identity recovery, and documentation you actually keep up. In my projects the configuration itself usually goes quickly. Lasting resilience only comes from repeated, realistic drills and from acting on what you learn in them. If you currently rely on backups alone for DR, have a look at Azure Backup Immutable Vaults for comparison, especially with ransomware in mind. Microsoft's documentation covers the details step by step: enabling replication, running a DR drill and recovery plans.