Azure Site Recovery

About Azure Site Recovery

Azure Site Recovery is Microsoft Azure's managed disaster recovery service for replicating supported virtual and physical workloads to a secondary location, coordinating failover during an outage, and failing workloads back after the primary environment is restored. It is designed for business continuity scenarios where organizations need more than backup copies: they need a repeatable way to keep applications available by bringing replicated machines online elsewhere. Site Recovery supports Azure-to-Azure disaster recovery as well as supported on-premises VMware, Hyper-V, physical server, Azure Stack and selected AWS-to-Azure scenarios. Buyers should validate the exact source platform, operating system, region, disk and networking requirements before treating the service as a universal replication layer.

What is Azure Site Recovery used for?

Azure Site Recovery is used when an organization needs a disaster recovery plan for machine-based workloads rather than only a way to restore files or backups. Microsoft positions the service around replication, failover, failback and disaster recovery testing. Supported scenarios include Azure virtual machines replicating between regions, selected zone-to-region scenarios, on-premises VMware and Hyper-V virtual machines, physical Windows and Linux servers, Azure Stack virtual machines and selected AWS Windows instances replicating to Azure.

The service continuously replicates supported workloads to a secondary location so they can be brought online when the primary site or region is unavailable. For Azure VMs and VMware VMs, Microsoft documents continuous replication. Hyper-V replication can be configured with intervals as low as 30 seconds. The practical recovery outcome still depends on the protected workload, replication health, network design, application dependencies and how frequently the organization tests its recovery process.

How do failover, failback and disaster recovery drills work?

Site Recovery supports planned failover for expected maintenance and unplanned failover for outages. Microsoft states that planned failover can provide zero data loss when the source environment is available and all pending changes can be synchronized. Unplanned failover can involve some data loss depending on the most recent recovery point and replication state. After the original environment is ready again, workloads can be failed back according to the supported scenario.

A major operational benefit is test failover. Microsoft allows organizations to run disaster recovery drills without stopping ongoing replication. This gives teams a way to validate that virtual machines start, networks are reachable and application dependencies behave as expected before a real incident. A recovery plan that has never been tested should not be treated as a proven recovery design.

What are recovery plans and application-consistent recovery points?

Recovery plans help sequence the recovery of multi-machine applications. Microsoft documents recovery plans that group protected machines, define startup order and optionally include scripts or manual actions. A recovery plan can contain up to 100 protected instances. This is useful for applications where databases, middleware and front ends must start in a deliberate sequence rather than all at once.

Site Recovery can also create application-consistent recovery points for supported workloads. Microsoft describes these snapshots as capturing disk data plus in-memory data and transactions in process. Application-consistent points can reduce the amount of application recovery work after failover, but they are not a substitute for application-native consistency, database protection or testing. Teams should verify that the workload and replication scenario support the recovery behavior they require.

How does Azure Site Recovery pricing work?

Pricing was checked against Microsoft's current Azure Site Recovery pricing page on August 26, 2026. Microsoft bills Site Recovery primarily by the average daily number of protected instances over the month. Each protected instance is free for its first 31 days of protection. From day 32 onward, the Site Recovery service charge applies according to the destination scenario and current regional pricing.

The service charge is only part of the cost. Microsoft also documents charges for replica storage, storage transactions and outbound data transfer when traffic leaves an Azure region. Test failovers and real failovers can create additional storage and compute charges because target virtual machines and disks are used during recovery. Buyers should model protected instance count, source data churn, target storage, test frequency, egress and the compute footprint that will run after failover rather than budgeting only for the per-instance Site Recovery fee.

How is Azure Site Recovery different from Azure Backup?

Azure Backup and Azure Site Recovery solve different recovery problems. Azure Backup protects data and creates recovery points that can be restored after deletion, corruption, ransomware or other data-loss events. Site Recovery is focused on keeping workloads available by continuously replicating supported machines and orchestrating their startup at a secondary location.

A business may need both. Backup provides historical recovery and retention, while Site Recovery can reduce downtime when an entire machine, site, zone or region is unavailable. Site Recovery should not be used as the only protection against accidental deletion or corruption because replicated problems can also reach the secondary copy. Backup should not be treated as an automatic low-downtime failover system because restoring large workloads can take longer than starting already replicated machines.

What limitations and design checks matter before deployment?

Site Recovery support varies by source platform, operating system, disk type, region, networking and workload configuration. Microsoft publishes separate support matrices for Azure VMs, VMware, Hyper-V and other scenarios. The Azure-to-Azure support matrix was updated August 12, 2026, which is a reminder that buyers should check the current matrix rather than rely on older migration guides or assumptions.

Replication also consumes storage, network bandwidth and source or target resources. High-change workloads need special attention. Microsoft currently documents a High Churn option for Azure VMs with data churn up to 100 MB/s, but eligibility and architecture requirements still need to be checked. Applications with shared disks, complex clustering, external dependencies or strict data-residency rules require scenario-specific validation. Recovery time and recovery point objectives should be measured through drills, not inferred from the service name.

Who should choose something else?

Organizations that mainly need long-term retention, protection from accidental deletion or historical restore points should start with Azure Backup rather than Site Recovery. Cloud-native applications already designed for active-active or multi-region operation may get better resilience from application-level replication, managed database geo-replication, global traffic routing and infrastructure-as-code instead of replicating whole virtual machines. Very small workloads may also find backup-and-redeploy simpler if the business can tolerate the recovery time.

Azure Site Recovery is strongest when an organization has machine-based workloads that need orchestrated disaster recovery across Azure regions or from supported on-premises environments into Azure. Buyers should choose it when replicated standby capacity, coordinated failover and regular non-disruptive recovery drills solve a clear business continuity requirement, and when the team is prepared to maintain recovery plans, network design, replication health and testing as ongoing operational responsibilities.