Home / Azure

AzureRunbookAdvanced

Azure Site Recovery: fixing replication health and running a test failover

Fix common replication health errors, then run a non-disruptive test failover into an isolated network and clean up afterwards.

Deepak Bhardwaj2 min read

Applies toAzure Site Recovery for Azure-to-Azure VM replication

Replication health checks

In the vault, open Replicated items and filter on Replication health: Critical/Warning. Check RPO, the last recovery point time and the error ID.

Common errors:

Error Cause Fix
High churn / RPO exceeded Disk writes faster than the replication limit Use Premium SSD target and cache storage. Split hot data. Check the per-disk churn limits.
Mobility service / extension failures (150xxx) VM can't reach Site Recovery endpoints Allow outbound HTTPS to the Site Recovery, Storage and Entra ID service tags, or the required URLs
Crash-consistent only (no app-consistent points) VSS failure (Windows) or pre/post script failure vssadmin list writers. Fix failed writers or free disk space for shadow copies.
Disk added but not protected New data disk after protection was enabled Enable replication for the new disk in replicated item settings 
# Windows: check VSS writers on the source VM
vssadmin list writers | Select-String -Pattern "Writer name|State|Last error"

Prepare the test failover

  • A dedicated test VNet in the target region, not peered to production. A test failover into the live network causes duplicate IPs and hostnames.
  • Choose the recovery point: Latest processed for low RTO, or Latest app-consistent for databases.
  • Make sure the test VNet has what the application needs: a DNS server or DC replica, jump host and test clients.

Run it

Portal: Recovery Plan → Test failover, choose the recovery point and the test VNet. Recovery plans let you order VMs in groups (DB → app → web) and add scripts or manual actions between groups.

Validate with an actual checklist:

  1. VMs boot and the agents report.
  2. The application answers health checks from a test client inside the test VNet.
  3. The database is consistent (run DBCC / app checks).
  4. Record the time from start to working app. That's your measured RTO.

Clean up

Cleanup test failover deletes the test VMs. Add notes about what failed. Until you clean up, the item shows a warning and you can't start another test failover.

Warning

A planned or unplanned failover (not a test) moves production. Run those only through your DR process and change approvals. Afterwards, plan re-protect and failback.

Prevent DR surprises

  • Run a test failover at least twice a year and after major application changes.
  • Alert on RPO above your target and on replication health changes.
  • Keep the target region's quotas (vCPU per family) big enough for a full failover.

Related fixes