Azure Site Recovery

About Azure Site Recovery

Azure Site Recovery is Microsoft's managed disaster recovery service for replicating supported virtual and physical workloads to a secondary Azure location, coordinating failover, testing recovery, and failing workloads back after the primary environment is restored. It is designed for workloads where restoring from backup alone would take too long and the business needs a rehearsed way to bring replicated machines online elsewhere. Site Recovery supports Azure-to-Azure disaster recovery and supported on-premises VMware, Hyper-V, physical server, Azure Stack, and selected other scenarios. Buyers should validate the current support matrix, region pair, operating system, disk, network, replication architecture, and recovery design before assuming every workload is eligible.

What is Azure Site Recovery used for?

Azure Site Recovery is used for machine-based disaster recovery where the objective is to reduce downtime by keeping a replicated copy of a supported workload ready in a secondary location. Microsoft positions the service around replication, planned and unplanned failover, failback, monitoring, and disaster recovery testing. Azure virtual machines can replicate between supported regions or availability zones, while supported on-premises VMware, Hyper-V, and physical machines can replicate into Azure.

The important distinction is that Site Recovery is not simply another backup product. It continuously moves supported workload changes toward a recovery target so a business can start replicated machines when the source environment is unavailable. The real recovery outcome still depends on replication health, available target compute capacity, networking, DNS, application dependencies, and whether the organization has tested the procedure.

What changed for VMware and physical server protection in 2026?

Microsoft retired the classic Azure Site Recovery experience for VMware and physical machine protection on March 30, 2026 and directs customers to the modernized experience. New protection through the classic architecture had already been blocked. Organizations that did not migrate should not treat the classic configuration as a supported disaster recovery operating model.

The modernized experience uses the newer Site Recovery replication appliance and receives current improvements and newer operating-system support. Microsoft also documents an important migration detail: recovery plans are not migrated from the classic Recovery Services vault and must be recreated in the modernized vault. Teams should therefore inventory recovery-plan groups, startup sequencing, scripts, manual actions, and application dependencies before migration, then rebuild and test those plans after the replicated items move. The migration itself is not a substitute for a fresh test failover.

How much data churn can Azure Site Recovery protect now?

Microsoft's current High Churn guidance allows eligible Azure virtual machines to reach up to 500 MB/s of data change per VM, a substantial increase from the older 100 MB/s ceiling. The default Normal Churn option supports up to 54 MB/s per VM. High Churn uses Premium Block Blob storage for the cache account and is available only for Azure-to-Azure disaster recovery.

The maximum is not automatic. Microsoft ties eligibility to VM memory, source disk type and size, I/O size, region, and Mobility service version. VMs with less than 32 GB of RAM are capped at 54 MB/s. VMs with 32 GB to less than 256 GB can reach up to 100 MB/s. Reaching up to 500 MB/s requires at least 256 GB of RAM and supported Premium SSD v1, Premium SSD v2, or Ultra Disk source storage, with per-disk limits also applying. Linux support above 100 MB/s is limited to supported RHEL 9, SLES 15, and Ubuntu 24.04 configurations. Buyers protecting high-write databases should check the current support matrix rather than treating 500 MB/s as a universal service limit.

How do failover, failback, and disaster recovery drills work?

Site Recovery supports planned and unplanned failover for supported scenarios. Planned failover is intended for controlled events where the source environment remains available long enough to synchronize outstanding changes. Unplanned failover is used when the source is unavailable and can involve some data loss depending on the most recent usable recovery point.

Test failover is one of the service's most important operational capabilities because organizations can rehearse recovery without stopping ongoing replication. A useful drill should test more than whether a VM boots. Teams should validate network connectivity, DNS, identity, application dependencies, security controls, monitoring, and business transactions. Microsoft's reliability guidance recommends regular disaster recovery drills, including quarterly or biannual testing for production workloads.

How should Site Recovery be designed for zone and region failures?

Microsoft recommends placing the Recovery Services vault in the target region for Azure-to-Azure disaster recovery. If the vault region itself is unavailable, replication can continue, but management operations such as failover and failback are unavailable until that vault region recovers. Microsoft also recommends on-demand capacity reservations when target compute availability is critical during a regional outage.

For Azure-to-Azure replication, Microsoft recommends zone-redundant storage for the cache account so a single zone failure does not interrupt access to recently changed cached data when the rest of the replication path remains healthy. The Recovery Services vault has its own storage redundancy setting, but Site Recovery does not use that vault redundancy setting for replication configuration resiliency. For the temporary cache account, Microsoft also advises against geo-redundant storage because the cache is only a staging location before data is replicated to the target. Buyers should check current regional zone-resilience support because the Site Recovery core service and vault are not yet zone resilient in every Azure region.

What are recovery plans and application-consistent recovery points?

Recovery plans help coordinate multi-machine applications by grouping protected instances, defining startup order, and optionally adding scripts or manual actions. Microsoft supports up to 100 protected instances in a recovery plan. This is useful for applications where databases, middleware, identity components, and front ends should not all start at the same time.

Supported workloads can also use application-consistent recovery points. These are intended to capture disk data together with in-memory state and in-process transactions where the application and replication scenario support that behavior. They can reduce post-failover recovery work, but they do not replace application-native consistency controls or workload-specific backup. Recovery plans and recovery points should be validated in drills because configuration alone does not prove an application will recover cleanly.

How does Azure Site Recovery pricing work?

Pricing was rechecked against Microsoft's Azure Site Recovery pricing page on September 4, 2026. Microsoft bills Site Recovery using the average daily number of protected instances during the month. Every protected instance is free for its first 31 days of protection. From day 32 onward, the Site Recovery service charge applies according to the protection scenario, region, currency, and customer agreement.

The free first 31 days do not make the overall disaster recovery footprint free. Microsoft separately documents charges for replica storage, recovery point snapshots, storage transactions, and outbound data transfer when replication leaves an Azure region. Test failovers and real failovers can add compute cost when target virtual machines run. Buyers should model protected instance count, data churn, target storage, drill frequency, egress, snapshot usage, and the expected compute footprint during recovery.

How is Azure Site Recovery different from Azure Backup?

Azure Backup and Azure Site Recovery address different recovery needs. Azure Backup creates retained recovery points for restoring data after deletion, corruption, ransomware, or other data-loss events. Site Recovery focuses on workload availability by replicating supported machines and orchestrating their startup at a secondary location.

Many organizations need both. Backup protects historical recoverability, while Site Recovery can reduce downtime during site, zone, or regional failures. Replication should not be the only defense against corruption because bad changes can also reach the replica. Backup should not be treated as a low-downtime failover service because restoring large workloads may take much longer than starting already replicated machines.

What limitations should buyers check before deployment?

Support varies by source platform, operating system, disk type, region, network design, and workload configuration. High Churn beyond 100 MB/s has additional memory, disk, operating-system, and regional requirements. The 500 MB/s figure is a maximum for eligible Azure-to-Azure workloads, not a promise for every VM. Shared disks, clustering, unsupported extensions, high write rates, and external application dependencies can all change the design.

Site Recovery also depends on operational hygiene. Microsoft strongly recommends automatic updates for Site Recovery agents. If an agent falls more than four versions behind, Microsoft states that replication is turned off and recoverability is compromised. Teams that manage updates manually should monitor the vault for agent update notifications and Critical Upgrade status, validate target capacity, configure replication-health alerts, and keep recovery plans current. Recovery time and recovery point objectives should be measured through exercises rather than inferred from service marketing.

Who should choose something else?

Organizations that mainly need long-term retention, point-in-time restoration, or protection from accidental deletion should start with Azure Backup. Cloud-native applications already designed for multi-region active-active operation may achieve better resilience through application-level replication, managed database geo-replication, global traffic routing, and infrastructure as code rather than replicating entire virtual machines.

Very small workloads may also prefer backup and redeployment if the business can tolerate a longer recovery window. Azure Site Recovery is strongest for supported machine-based workloads where replicated standby capacity, coordinated failover, failback, and non-disruptive disaster recovery drills solve a clear continuity requirement and the organization is prepared to maintain the design as an ongoing operational capability.