Before meeting any tool, understand the pain it removes. Once the pain is clear, every feature of Azure Site Recovery looks sensible instead of random.

Things go wrong, even in the cloud

People often believe that moving to the cloud makes outages impossible. It makes many failures rarer, but it does not abolish them. Cloud providers build data centers with great care, yet a facility can still lose power, a network cable can be cut, a software update can go wrong, or a natural disaster can strike a region. Inside your own organisation, a mistaken command can delete servers, and ransomware can lock every disk. Disaster recovery is the discipline of being ready for such days.

Two numbers that rule everything

Disaster recovery planning revolves around two measurements. The first is the Recovery Point Objective (RPO): how much recent data you can afford to lose, measured in time. An RPO of five minutes means that after a disaster you may lose, at most, the last five minutes of work. The second is the Recovery Time Objective (RTO): how long the business can stay down, measured from the disaster until service is running again. An RTO of one hour means the systems must be back within sixty minutes.

Backups are not enough

A backup is a stored copy of data from a past moment. If you lose data, you restore it. Backups are essential, but restoring a large environment from backups can take hours or days: servers must be rebuilt, networks configured, data copied back, and applications started in the right order. A disaster recovery solution keeps a nearly ready copy of whole servers in another location, so that recovery means switching on prepared machines rather than rebuilding from scratch. The two are partners, not rivals: backups protect against deletion and corruption over time, while disaster recovery protects against loss of a whole site or region with short downtime.

The old way was painful and expensive

Traditionally, companies built a second data center with matching hardware, matching software, and a team to keep them in sync. It sat mostly idle, cost nearly as much as the first, and was tested rarely because tests were hard. When a real disaster came, many discovered that the copy was out of date or that no one remembered the startup order. The cloud changes the economics: the copy can live in Azure storage at modest cost, and the compute that runs the machines is paid for only when you actually fail over.

An illustrative example

Consider a hypothetical online insurance company with a customer portal, a policy database, and a payment gateway, running on 40 virtual machines in a data center. Management sets an RPO of 15 minutes and an RTO of two hours. With Azure Site Recovery, all 40 machines are replicated continuously to Azure. Every quarter, the team runs a test failover into an isolated network and checks that the portal works. When a real fire damages the data center, they run one recovery plan, the machines start in the correct order in Azure, the DNS record is updated, and customers are back within the hour with at most a few minutes of data lost.

Azure Site Recovery has a modest vocabulary. Learn these words once, and every later chapter reads easily.

The words, one at a time

A mental picture in five lines

You create a vault. You choose which servers to protect and a policy for them. Site Recovery starts replicating their disks to the target, and keeps a rolling set of recovery points. You build a recovery plan and rehearse it with test failovers. In a real disaster, you run a failover, choose a recovery point, and the replicated copies start as live servers. Later, you reprotect and fail back once the original site is healthy.

What is and is not stored while waiting

While replication runs, the target holds only the disks of your servers (as storage), not running machines. The compute, meaning the processors and memory that actually run the server, is not charged until you perform a failover or a test failover. This is the central reason why Site Recovery is far cheaper than keeping a full duplicate environment running.

Azure has several features that sound alike: backup, availability zones, geo-redundant storage, and migration tools. Putting Site Recovery beside them makes its job clear.

A short history

Microsoft first offered a disaster recovery service for Hyper-V virtualisation hosts in the early 2010s, orchestrating replication between a company’s own sites. It soon grew to protect VMware machines and physical servers by replicating to Azure, and later to protect Azure virtual machines by replicating them from one Azure region to another. The service name settled as Azure Site Recovery, often shortened to ASR. Over the years it also served as a migration tool, since failing over a replicated server into Azure is effectively moving it. Today, Microsoft recommends Azure Migrate for new migrations, while Site Recovery stays focused on disaster recovery, and the two tools share some technology.

What Azure Site Recovery does

Site Recovery versus Azure Backup

Site Recovery versus built-in redundancy

Site Recovery and migration

You may see guides that use Site Recovery to move servers into Azure. That works, because replicating and failing over is a form of migration. For migrations, Microsoft’s current guidance centres on Azure Migrate, which provides discovery, assessment, and a replication engine. This guide focuses on disaster recovery, and notes where migration uses the same ideas. Check the current documentation for which tool is recommended for your scenario.

The architecture depends on what you protect. We start with the most common case, Azure virtual machines replicated to another Azure region, then look at servers outside Azure.

flowchart LR
  subgraph SRC["Source region"]
    VM1["Protected VM with Mobility service extension"]
    DSK["Source managed disks"]
    CACHE["Cache storage account"]
    VM1 --- DSK
    VM1 --> CACHE
  end
  subgraph VAULT["Recovery Services vault"]
    CTRL["Site Recovery control plane and recovery plans"]
  end
  subgraph TGT["Target region"]
    REP["Replica managed disks"]
    TVN["Target virtual network"]
    TRG["Target resource group"]
  end
  CACHE -->|"changes sent over Azure backbone"| REP
  VM1 -.->|"health and status"| CTRL
  CTRL -.->|"orchestrates failover"| TGT
  REP -->|"on failover, new VM is created from disk"| TVN

Azure to Azure

This design protects virtual machines that already live in Azure. When you enable replication, Site Recovery installs a small Mobility service extension inside each virtual machine. The extension watches for writes to the disks and sends changes to a cache storage account in the source region. From there, a Site Recovery process copies the changes over Microsoft’s private backbone network to replica managed disks in the target region. The target region has a resource group, a virtual network, and subnets prepared by you or created automatically. No target virtual machine exists until failover; the replica disks simply wait.

Servers outside Azure

The common parts

Why the vault sits in the target region

If the vault lived in the same region as the protected machines and that region failed, you could not reach the tool that orchestrates recovery. For Azure-to-Azure protection, the vault belongs in the target region, the one that survives the disaster. For on-premises sources, the vault is in the Azure region where you want to recover.

Region pairs and choices

Azure regions come in pairs, two regions in the same geography that are designed to be far enough apart to avoid sharing a single disaster, for example separate cities. Many companies pick the paired region as their target for simplicity. You can also choose other regions in the same geography when data-residency rules allow, or when you need specific services or capacity. Check that the target region offers the virtual machine sizes and features your workloads need, and that your subscription has enough quota there.

Follow a single disk write from a running server to its copy in another region, and you will understand almost everything about replication behaviour.

sequenceDiagram
  participant App as Application on VM
  participant MS as Mobility service
  participant CS as Cache storage
  participant ASR as Site Recovery service
  participant RD as Replica disk in target
  App->>MS: Write to disk
  MS->>MS: Capture the changed blocks
  MS->>CS: Upload changes to cache
  CS->>ASR: Changes available for processing
  ASR->>RD: Apply changes to replica disk
  MS->>MS: Every few minutes mark a crash consistent point
  MS->>MS: On schedule request application consistent snapshot
  ASR->>ASR: Store recovery point and remove expired points
  ASR-->>MS: Replication health reported to vault

Phase one: initial replication

When you first enable protection, the service must copy the entire contents of each disk to the target. This is the initial replication, and its time depends on the amount of data and the network capacity. A machine with 500 gigabytes of used data can take hours. During this phase the machine is not yet protected, and the health status shows it. Do not count the machine as covered until initial replication has finished and a first recovery point exists. Plan the start for a quiet period, and for on-premises sources consider the impact on your internet link.

Phase two: ongoing replication (delta)

After the first copy, only changes travel. The Mobility service tracks which blocks of the disk have been written and sends them as they happen. This is why the target stays within seconds or minutes of the source. The size of these changes per second is called data churn. A quiet web server has low churn. A busy database may have very high churn, and every disk type has limits on how much churn Site Recovery can handle, as documented by Microsoft. If churn exceeds what the network or the limits allow, replication falls behind and the actual RPO grows.

Recovery points

While changes flow, Site Recovery marks recovery points, moments you can later choose to start from. Two kinds exist.

• Crash-consistent recovery points are created frequently, typically every few minutes. They capture all disk writes up to a moment, but not data still sitting in application memory. Starting from such a point is like restarting a computer after a sudden power cut. Operating systems and well-designed databases usually recover fine, but this is not guaranteed.
• Application-consistent recovery points are created less often, on a schedule you choose in the policy, commonly every few hours. Before taking one, the service asks the operating system, using a snapshot facility such as Windows Volume Shadow Copy Service or Linux pre- and post-scripts, to tell applications to flush data and pause writes briefly. The result is a tidy copy where applications start cleanly.

Retention

The replication policy sets how long recovery points are kept. Because points are stored as changes on top of the replica disks, keeping more of them uses more storage. The default is short, commonly 24 hours, and the maximum is measured in days, not months. If you need to recover to a time months ago, that is a job for backup, not Site Recovery.

RPO in practice

For Azure-to-Azure, the achieved RPO is usually seconds to a few minutes, but it is not a promise. It depends on churn, network throughput, and the health of the service. The portal shows the current RPO per machine, and you can set alerts if it exceeds your threshold. Treat the displayed figure as your real-time measurement, and set the alert threshold lower than your business target so that you have time to react.

What is replicated and what is not

• Replicated: the operating system disk and data disks attached to the machine, with their contents.
• Not replicated automatically: shared resources outside the machine such as load balancers, firewalls, DNS records, key vaults, and platform databases. You must plan for these separately, usually with infrastructure as code in the target region.
• Memory contents: not captured. Recovery starts the machine fresh from its disk, so running processes restart.

Site Recovery supports many sources and targets, but not everything. Knowing the boundaries early prevents unpleasant discoveries during a disaster.

Supported scenarios at a glance

Typical requirements for Azure virtual machines

• The machine runs a supported Windows or Linux version. Very old or custom kernels may not work.
• Disks are managed disks, or unmanaged disks within supported limits, and each disk is within the size limits.
• The machine can reach required Azure service addresses outbound, so the Mobility service can talk to the cache storage and the service.
• The target region supports the machine’s size, features, and any special hardware.
• Certain features need extra attention: disk encryption, proximity placement groups, availability zones, ultra disks, and shared disks have specific rules.

What Site Recovery does not cover

Designing with the boundary in mind

Treat Site Recovery as the machinery for virtual machines, within a bigger disaster recovery design. A complete design lists every component of the application, decides how each one will be recovered, and puts the answers in a single document. A customer portal may have web servers (Site Recovery), a SQL database (geo-replication or a failover group), static files in storage (geo-redundant storage), a front door that sends traffic (global load balancer), and secrets (a second vault in the target region). Site Recovery handles one line of that list.

Setup is a short sequence of decisions. Each decision has a consequence for cost, safety, and recovery speed.

The setup journey

The replication policy

Per-machine target settings

For each protected machine you can control where its replica lives and what it will look like on failover: the target resource group, virtual network, subnet, availability setting, and disk type. You can also choose a different size for the target machine, which is useful for saving money when a smaller footprint is enough during an emergency, or when the same size is unavailable. Settings can be changed later, but some changes require disabling and re-enabling replication, so verify before you start.

Automation and scale

For more than a handful of machines, avoid clicking. Use Azure Policy to deploy replication to tagged machines, scripts or templates to enable protection, and Azure Resource Graph to report coverage. This ensures new virtual machines are not forgotten, a frequent source of failed disaster recovery tests: “we protected everything except the three servers added last month.”

Protecting machines you add later

• Include protection in your standard build process, so that no server goes live without it unless approved.
• Run a periodic report of machines in production that are not protected, and give owners a deadline.
• When machines are resized, disks added, or networks changed, check that replication settings still match.
• When machines are retired, disable replication so you do not pay to protect machines that no longer exist.

A server that starts in the recovery site but cannot be reached is not recovered. Networking is the most common reason that disaster recovery plans fail on the day.

The core problem

Your source environment has addresses, firewall rules, load balancers, and name records that make it reachable and connected to other systems. A recovered virtual machine starts in a different network, possibly in a different geography. Unless you prepare the target network ahead of time, the machine may start with the wrong address, behind the wrong firewall, with no route to its database, and unknown to its users.

Network mapping

Network mapping tells Site Recovery which target network and subnet should host a failed-over machine from each source network and subnet. Without a mapping, the service picks a default or fails. For Azure-to-Azure, a mapping connects the source virtual network to the target virtual network. Plan address ranges so that the networks do not overlap if you want them connected.

flowchart TD
  USERS["Users on the internet"] --> GLB["Global traffic routing such as Front Door or Traffic Manager"]
  GLB -->|"normal operation"| LBP["Primary region load balancer"]
  GLB -.->|"after failover"| LBS["Secondary region load balancer"]
  LBP --> WEBP["Primary web VMs"]
  LBS --> WEBS["Recovered web VMs"]
  WEBP --> DBP["Primary database"]
  WEBS --> DBS["Recovered or replicated database"]
  DNS["Private DNS and name records"] --> WEBS
  FW["Firewall rules and NSGs prepared in secondary"] --> WEBS
  VPN["VPN or ExpressRoute to office"] --> LBS

Addressing choices

Whichever approach you choose, fix addresses for recovered machines in the settings so they are predictable. Applications should use names, not raw addresses, whenever possible, which makes address changes painless.

Names and traffic: DNS and global routing

Users reach your application through names such as portal.example.com. After failover, that name must lead to the recovered servers. There are two common ways. One is a DNS update: change the record to the new address, accepting that caches around the world will take time to expire, so set a short time to live (TTL) in advance. The other is a global traffic manager, such as Azure Front Door or Azure Traffic Manager, which watches health and sends users to whichever region is healthy. The second approach is faster and less manual, and is preferred for public applications.

Load balancers, firewalls, and security groups

• Load balancers and application gateways are not replicated. Create equivalents in the target region and add recovered machines to their back-end pools, either through the recovery plan or through scripts. Site Recovery can attach recovered machines to a pre-created load balancer if you configure it.
• Network security groups and firewall rules must exist in the target with matching rules. A forgotten rule means a recovered machine silently blocks traffic.
• Public IP addresses in the target are different from the source. Plan for new public entry points.
• Private connectivity such as VPN or ExpressRoute from offices and partners must also be available in the target region.
• Dependencies on other systems such as identity servers, DNS servers, and monitoring must be reachable from the target network.

Connectivity for the service itself

The Mobility service and Site Recovery need outbound access to certain Azure service addresses for cache storage, the vault, and identity. If your machines sit behind a firewall or proxy, allow these addresses, or use service tags in network security groups. In locked-down environments, private endpoints for the vault and storage can keep replication traffic off the public internet. Microsoft publishes the lists of required addresses and the supported private options, which change occasionally.

A real application is not one server. It is a family of servers that must start in a sensible order. Recovery plans capture that order.

What a recovery plan is

A recovery plan groups machines and describes the steps for failing them over together. It is a document the service can run. Machines are placed into groups, which start one after another. Within a group, machines start in parallel. Between groups, you can add pre-actions and post-actions, which are manual steps for a human to confirm or automation scripts that run at defined points.

flowchart TD
  START["Start recovery plan"] --> G1["Group 1 Identity and DNS servers"]
  G1 --> A1["Post action check domain controller health"]
  A1 --> G2["Group 2 Database servers"]
  G2 --> A2["Post action attach database storage and verify"]
  A2 --> G3["Group 3 Application servers"]
  G3 --> A3["Post action run script to update settings"]
  A3 --> G4["Group 4 Web servers"]
  G4 --> A4["Post action add to load balancer and update traffic routing"]
  A4 --> DONE["Plan complete and verify application"]

Why order matters

• Identity and name services first. Domain controllers and DNS must be up before servers that need to authenticate or look up names.
• Databases before applications. Applications that start without their database may crash or cache an error state.
• Applications before web front ends. The front end should not accept customers until the back end is ready.
• Traffic last. Direct users to the recovered site only after checks pass.

Automation inside plans

Good recovery plan habits

• Create one plan per application or per tier of related applications, not one giant plan for everything.
• Keep scripts simple, tested, and idempotent, meaning running them twice causes no harm.
• Store scripts in source control, and keep a copy of the plan description outside the primary region, because documentation held only in the failed region is useless.
• Include a verification step at the end: a health check or smoke test that proves the application works.
• Design plans so they can run both ways: failover to the secondary and failback to the primary after reprotection.
• Version plans, and review them whenever the application changes.

Scale of plans

Plans have documented limits on the number of machines and groups. For very large estates, split protection into several plans, run in a planned sequence with a coordinating runbook or human leader. Check the current limits.

These four activities form the life cycle of a real recovery. Learn them in the order you will use them.

flowchart LR
  A["Normal operation in primary region"] --> B["Replication to secondary"]
  B --> C["Test failover in isolated network"]
  C --> D["Cleanup test resources"]
  D --> B
  B --> E["Disaster in primary"]
  E --> F["Failover to secondary"]
  F --> G["Commit the failover"]
  G --> H["Run on secondary"]
  H --> I["Primary repaired"]
  I --> J["Reprotect to reverse replication"]
  J --> K["Failback to primary"]
  K --> L["Reprotect again to original direction"]
  L --> A

Test failover: the fire drill

A test failover creates copies of your machines from a recovery point in a separate, isolated virtual network. Production keeps running, and replication continues undisturbed. You log in to the test machines, check that applications start and data looks right, and then clean up, which deletes the test machines. Test failover is the single most valuable feature of the service, since a plan that has never been tested is only a hope.

• Run tests regularly, at least every few months, and after any major change in the application or network.
• Test with realistic scenarios, including starting the whole application from the recovery plan and verifying functionality from a user’s point of view.
• Time the test, and compare the result with your RTO.
• Record findings, fix what failed, and repeat.
• Remember that test machines cost money while they exist. Clean up promptly.

Failover: the real thing

In a real disaster, you run a failover on a machine or a recovery plan. The steps are as follows.

Planned versus unplanned failover

An unplanned failover responds to a real or simulated disaster, accepting that some recent data may be lost because the source might not be able to send its last changes. A planned failover, available for some scenarios such as on-premises VMware and Hyper-V sources, first shuts down the source machines and sends the final changes, so no data is lost. Planned failovers suit expected events, like moving out of a building, or a drill that uses a real switch. Check which options exist for your scenario.

Reprotect and failback

After failover, the recovered site is running without any safety net: its own copy no longer exists. Once the original site is repaired, you perform reprotect, which reverses replication so that changes made in the recovery site flow back to the original. After the original is up to date, you fail back, switching the live workload back. For Azure-to-Azure, the process re-creates virtual machines in the original region. For on-premises sources, failback copies data back to the on-premises environment, which may require additional components and bandwidth.

• After failback, reprotect again to resume the original direction of protection.
• Allow time for resynchronisation, which can be lengthy for large disks.
• Run failback during a quiet period, and plan another user redirection and verification.

Common failover decisions

Technology is the easy part. The harder, more valuable part is deciding what to protect, to what level, and at what cost.

Start with the business

The right question is not “can we replicate everything?” but “what happens to the business if each system is down for an hour, a day, a week?” A business impact analysis assigns each application a cost of downtime, measured in lost sales, legal penalties, and damaged trust. That cost guides how much to invest in protection. A printing queue server and a payment gateway do not deserve the same recovery target.

Tiering applications

These figures are examples to show the idea. Your own numbers come from the business.

Strategies from cheap to expensive

Choosing the target region and mode

• Distance. Far enough to avoid the same disaster, close enough to keep replication latency and legal boundaries acceptable.
• Data residency. Laws may require data to stay in a country or a regional group.
• Service availability. The target must offer the same virtual machine sizes, storage types, and features.
• Quota and capacity. Request enough cores in advance. For the most critical systems, consider capacity reservations in the target region to guarantee that machines can start.
• Zone-to-zone option. When the main risk is the loss of a data center building and not a region, zone-to-zone disaster recovery protects within one region with lower latency and no cross-region data transfer, while keeping the same orchestration.

Document the whole application

For each application, write a one-page recovery sheet. It should name the owner, the tier, the RPO and RTO, every component and how it is protected, the order of recovery, dependencies, contact details, the location of the runbook outside the primary region, and the date of the last successful test. This sheet is the thing people reach for under stress.

Copying disks is easy. Making sure the copy actually works as an application is the real challenge, especially for databases and for systems made of several servers.

Why consistency matters

A database writes to several files at once: data files, log files, and index files. If a copy captures the data file at one moment and the log at another, the pieces may not agree, and the database refuses to start or, worse, starts with silent damage. Consistency means that the copy represents one coherent moment. Site Recovery gives you tools for this, but you must choose and test them.

Single-machine consistency

For one machine, crash-consistent points are usually enough for modern file systems and well-built databases, which can replay their logs after an abrupt stop, just as they do after a power cut. For systems where you want a clean state, such as older databases or applications that cache heavily, application-consistent points are safer. On Windows, they rely on the Volume Shadow Copy Service and application writers such as SQL Server’s. On Linux, they use pre- and post-snapshot scripts that you provide to quiet the application.

Multi-machine consistency

Some systems spread state across several machines: a clustered database, an application server plus a message broker, or a sharded data store. If each machine is recovered to a slightly different moment, the system as a whole can be inconsistent. A replication group with multi-VM consistency makes the machines share common recovery points. The cost is extra overhead and the requirement that machines communicate with each other regularly during snapshot creation. Use it only when needed, and keep the group small. Check the documented limits on group size.

Databases need their own plan

Identity and directory servers

Domain controllers need special care. Restoring an old copy of a domain controller can cause replication conflicts across the directory. Microsoft recommends that for Active Directory you use a design in which additional domain controllers already exist in the recovery location, kept up to date by normal directory replication, rather than relying on replicating domain controller disks. If you do use Site Recovery for them, follow the specific guidance for the supported version. Cloud identity from Microsoft Entra ID is global and does not need regional failover.

Other special cases

• Clusters with shared disks. Some shared disk clusters have limited or special support. Check the matrix, and prefer application-level clustering or replication across sites.
• Licence-bound software. Software tied to hardware identifiers or addresses may stop working after recovery. Talk to vendors about disaster recovery licensing.
• Time-sensitive systems. Systems that depend on clocks, such as certificates or tokens, may need checks after a long gap.
• Scheduled jobs. Decide whether batch jobs resume automatically after failover, or whether someone reviews first, to avoid duplicates.
• Outbound integrations. Partners may allow only certain source addresses. Update them or use fixed outbound addresses planned for both regions.

A recovery site holds a full copy of your most valuable systems and the power to take over production. It must be guarded as carefully as the original.

Who may do what

Assigning a custom mix is possible. Enabling replication for Azure virtual machines also needs rights on the machines, the target resource group, and the network, so teams often combine Site Recovery roles with Virtual Machine Contributor on specific scopes. Keep the ability to run production failover with a small, trained group, and give wider read access so that operations and auditors can see status.

Protecting the vault and the recovery site

Encryption

• In transit. Replication traffic is encrypted. Between on-premises sources and Azure, data is sent over secure channels.
• At rest. Replica disks in Azure are encrypted with platform-managed keys by default. You can use customer-managed keys through disk encryption sets where your policy demands it, and the target must have matching key vault and keys.
• Azure Disk Encryption. Machines that use it need extra steps: key vaults, key permissions, and target-region key access must be set up so that recovered machines can unlock their disks.
• Keys in the target region. If keys exist only in the failed region, you cannot start encrypted machines. Plan key replication or a key vault in the recovery region.

Ransomware and malicious deletion

An attacker with administrator rights may try to disable replication, delete replica disks, or destroy the vault so that you cannot recover. Defences include strong identity protection, alerts and locks, separate administration for the recovery site, and independent immutable backups held in a different security boundary. Remember that replication reproduces bad data quickly, so Site Recovery alone is not a ransomware defence; it must be combined with backup and clean recovery points.

Compliance and audit

Auditors often ask for evidence of regular disaster recovery tests. Keep records: test dates, scope, results, issues, fixes, and sign-offs. The service shows job history and test failover results, which you can export. Make sure the recovery region meets the same compliance requirements as the primary, including residency, certifications, and logging.

Disaster recovery is insurance. A good design buys the protection you need at a price you can accept, and avoids waste.

What you pay for

A worked example

These figures are invented, to show the arithmetic only. Suppose a company protects 50 machines, each with 200 gigabytes of disks, so 10,000 gigabytes in total. Replica storage must hold roughly that much in the target region. Add a licence fee per machine per month, multiplied by 50. Add the small cache accounts, transfer of changed data, and recovery point overhead. Compare this with running 50 duplicate machines around the clock, which would add the full compute cost of 50 machines for the whole month. The difference, usually large, is the economic reason that replicate-and-start-on-demand is the default design. In a test failover lasting four hours, you pay only for four hours of compute for the machines you start.

Saving money wisely

Capacity and performance on the day

Failover performance has two parts. First, the time to create and start machines, which usually takes minutes per group, although large plans take longer. Second, the performance of the recovered machines. Disks restored from replica storage may be slower at first, especially if the replica used a lower tier. Network paths from users and dependencies may be longer. Recovered machines in a distant region may see higher delay to remaining systems left in the original region, such as an on-premises database. Test application performance during drills, not just whether it starts.

Many organisations still run servers in their own data centers and use Azure as the recovery site. The ideas are the same, with extra pieces on the local side.

Why Azure as a recovery site

Building a second physical data center is slow and expensive. Using Azure as the recovery site converts that capital cost into a modest monthly charge, with compute paid only when needed. It also gives geographic separation without a new building, and it can later become a stepping stone for moving workloads permanently to the cloud.

VMware and physical servers

Hyper-V

For Hyper-V, you install the Site Recovery provider and the Microsoft Azure Recovery Services agent on each host, register them with the vault, and enable protection on virtual machines. Replication is host-based, so you do not install an agent inside each guest machine. Some environments use System Center Virtual Machine Manager to manage clouds of hosts, and the provider integrates there.

Sizing the connection

The most common failure of on-premises setups is a link that is too small. To size it, estimate the daily change rate of all protected disks, convert to a sustained speed, and add a margin. Also consider the one-time cost of initial replication: terabytes over a modest link take days. Techniques include starting during quiet periods, throttling during business hours, and, where offered, shipping disks. If the link cannot keep up, the RPO grows steadily, and you may be unprotected without noticing.

Failing back to on-premises

After an on-premises failover, the site is repaired, and you want to return. The process reprotects the Azure machines, synchronises changes back to the on-premises environment, and then switches. It needs on-premises capacity ready, networking restored, and enough bandwidth to bring back the changes made while running in Azure. For long stays in Azure, plan for this carefully, and sometimes decide to remain in Azure and treat the failover as a permanent move.

A disaster recovery system that is broken without anyone noticing is worse than none at all, because it gives false comfort. Monitoring is how you keep the promise.

What to watch

Alerts and reports

• Enable email notifications and Azure Monitor alerts for replication health, RPO breaches, failed jobs, and failover events.
• Send vault diagnostics to a log workspace, and build a dashboard showing coverage, health, and the age of the latest test.
• Report weekly on unprotected machines in scope, using inventory queries.
• Track quota usage in the target region against the cores required for a full failover.
• Archive test reports as audit evidence.

Common problems and their usual causes

A calm method for investigating

Site Recovery is one tool in a larger toolbox. Matching each tool to the problem gives a better and cheaper design.

flowchart TD
  Q["What are you protecting against"] --> A{"Accidental deletion or corruption of data"}
  A -->|"Yes"| BK["Azure Backup with immutable vaults"]
  A -->|"No"| B{"Failure of a rack or host"}
  B -->|"Yes"| AS["Availability sets and zones"]
  B -->|"No"| C{"Loss of a data center building"}
  C -->|"Yes"| ZN["Zone redundant design or zone to zone Site Recovery"]
  C -->|"No"| D{"Loss of a whole region"}
  D -->|"Virtual machines"| SR["Azure Site Recovery"]
  D -->|"Platform databases"| GEO["Geo replication and failover groups"]
  D -->|"Stored files"| GRS["Geo redundant storage"]
  D -->|"Near zero downtime needed"| AA["Active active multi region design"]

The options compared

Combining tools

The best designs combine tools. A typical three-tier application might use infrastructure as code to rebuild stateless web servers, Site Recovery for the middle-tier application servers that are hard to recreate, a database’s own replication for data, geo-redundant storage for files, backup for history and ransomware recovery, and a global traffic manager to send users to the healthy region. Each does what it is best at.

Questions to settle the design

• What is the RPO and RTO for each application, and who has approved them?
• Which components can be rebuilt, which can be replicated, and which need native replication?
• What do we do about shared services, identity, DNS, certificates, and networks?
• Who is authorised to declare a disaster and run the plan?
• How often do we drill, and what do we do with the findings?
• How would we know if replication stopped working yesterday?

Teams that recover well repeat a few good designs. Teams that struggle repeat a few familiar mistakes. Knowing both saves painful lessons.

Patterns that work

Habits compared

Four decisions worth recording

Teams that write down their key decisions avoid arguing about them again a year later. These short records use the common format of context, decision, and consequences. They are illustrative examples, not mandates.

This chapter gathers the advice of the whole book into one checklist to use before launch, during reviews, and after incidents.

Best practices

Common mistakes

The following scenarios are invented illustrations built from common situations. They are not case studies of real companies, and the numbers are examples chosen to make the ideas concrete.

Short answers to the questions beginners ask most often.

You began with a bakery whose kitchen flooded overnight. You now have the blueprint for a second kitchen that is ready when you need it.

Azure Site Recovery continuously replicates the disks of your virtual machines and physical servers to another region or to Azure, keeping a rolling set of recovery points. Compute in the target is paid for only when you test or fail over. Recovery plans order the startup, test failovers prove the plan without disturbing production, failover switches the live workload, and reprotect and failback bring you home again. Around this machinery sit the decisions that decide success: business targets for RPO and RTO, a prepared target network and shared services, consistency choices for databases, security of the recovery path, honest cost planning, and continuous monitoring and rehearsal.