Azure Site Recovery: Keep the Lights On When Disaster Strikes
A friendly, step-by-step guide to how Azure Site Recovery copies your servers to a safe second location and brings them back to life during an outage, covering replication, recovery points, failover, failback, recovery plans, testing, networking, monitoring, and cost, with plain-English analogies throughout.
Imagine you run a busy restaurant. One night a pipe bursts and floods the kitchen, and you cannot serve a single meal. Customers are hungry, staff are standing around, and every hour closed costs money and reputation. Now imagine you had quietly prepared a second, fully equipped kitchen across town. Every day your recipes, ingredients list, and orders were copied there. When the flood hits, you simply call the backup kitchen, say “switch over,” and customers keep eating within minutes. That backup kitchen, together with the careful copying and the switch-over plan, is what Azure Site Recovery gives your software systems.
In this guide you will learn what Azure Site Recovery is, why it exists, how it copies and recovers systems, how teams plan and practice a recovery, and how to keep the whole thing organized and affordable. You do not need any background in disaster planning or cloud tooling. Every new word is explained the first time it appears.
1What Is Azure Site Recovery?
Azure Site Recovery is a managed service that replicates your workloads to a second location and helps you switch to it when the first one fails.
First, What Is a Disaster?
In computing, a disaster is any event that stops your systems from working for a long time. Some disasters are dramatic, such as fires, floods, earthquakes, or a power failure that takes down a whole datacenter. Others are quieter but just as damaging: a faulty software update that breaks every server, a network failure that cuts off an entire region, or a cyberattack that locks up machines. Whatever the cause, the result is the same. People cannot use your applications, and the business suffers.
What Is Disaster Recovery?
Disaster recovery, often shortened to DR, is the plan and the technology for getting your systems working again after such an event. Traditionally this meant renting a second datacenter, buying duplicate hardware that sat idle most of the year, and writing long manuals of manual steps. It was expensive, slow, and rarely tested, so many companies discovered during a real disaster that their plan did not work.
The Short Definition
Azure Site Recovery is a disaster recovery as a service offering from Microsoft. It continuously copies your servers, which it calls workloads, from a primary location to a secondary location. If the primary location fails, you trigger a failover, which starts copies of your servers in the secondary location so your applications can run there. When the primary location is healthy again, you can move back, which is called failback. The service is managed by Microsoft, so there is no second datacenter to build and no replication software for you to host and maintain yourself in the common Azure-to-Azure scenario.
Think of a theater with an understudy for every actor. The understudies watch every rehearsal and learn every line. If the lead actor falls ill ten minutes before curtain, the understudy steps onto the stage and the show goes on. Site Recovery keeps an “understudy” copy of each of your servers, ready to take the stage.
Supported scenarios, limits, and prices evolve over time. The concepts in this guide are the stable foundation. Always confirm exact numbers and supported operating systems in Microsoft’s current documentation.
2Why Does It Exist? The Problem It Solves
Outages are not a question of if, but when, and businesses need a way to keep running through them.
What Downtime Really Costs
When a system goes down, the cost is not only the repair. An online shop loses sales every minute its website is unavailable. A hospital may be unable to access patient records. A bank may be unable to process payments, and regulators may ask hard questions. Customers who cannot reach a service often switch to a competitor and may never come back. For many businesses, even a few hours of downtime is serious, and a few days can threaten survival.
The Old Way Was Heavy
Before cloud services, building disaster recovery meant buying a second set of servers, networking, and storage, placing them in a separate building, and paying for them every month even though they did nothing most of the time. Teams wrote long step-by-step documents describing how to rebuild each server, in what order, and with which settings. Practicing these steps meant scheduling downtime on real systems, so many companies rarely tested at all. When disaster finally came, steps were out of date, people were missing, and recovery took days.
It is like keeping a spare house fully furnished across the country in case your main house burns down. It works, but you pay for an empty house year-round. Site Recovery is closer to renting a hotel room only on the night you need it, while a small service quietly keeps a copy of your belongings ready.
What You Gain
Business Continuity
Applications can be running again in a second location in a short, planned time rather than days.
Lower Cost Than Duplicate Datacenters
You pay a modest per-server fee plus storage while replicating, and pay for full compute only when you actually fail over or run a test.
Practice Without Pain
Test failovers let you rehearse recovery in an isolated network without touching your live systems.
Ordered, Repeatable Recovery
Recovery plans start servers in the right order, so a database is ready before the application that needs it.
Many Workload Types
It can protect Azure virtual machines, VMware machines, Hyper-V machines, and physical servers.
Central Management
All replication, health, and recovery actions are managed from one place in the Azure portal.
3Two Numbers That Shape Every Plan: RPO and RTO
Before touching any tool, a recovery plan starts by answering two simple questions about time.
Recovery Point Objective
The recovery point objective, or RPO, answers: “How much data can we afford to lose?” It is measured in time. If your RPO is five minutes, you accept that after a disaster, the recovered system may be missing up to the last five minutes of changes. If your RPO is zero, you are saying you cannot lose anything, which requires much more expensive technology. The smaller the RPO, the more frequently data must be copied.
Recovery Time Objective
The recovery time objective, or RTO, answers: “How long can we be down?” It measures the time from the moment of disaster to the moment the application is working again. An RTO of one hour means the business is prepared to be offline for at most one hour. Faster recovery needs more automation and more preparation.
Imagine you are writing an important essay and your computer crashes. RPO is how much writing you are willing to redo, perhaps the last five minutes if the program autosaves that often. RTO is how long you are willing to wait before you can start typing again, perhaps the time it takes to reboot and reopen the file.
flowchart LR
A["Last good copy of data"] -->|RPO: data you may lose| B["Disaster strikes"]
B -->|RTO: time you are down| C["Applications running again"]
Different Systems, Different Targets
Not every system deserves the same investment. A payment system may need an RPO of seconds and an RTO of minutes. An internal reporting tool might tolerate losing a day of data and being offline for a day. Sorting systems into tiers by importance helps you spend money where it matters most.
| Tier | Example System | Typical RPO Goal | Typical RTO Goal |
|---|---|---|---|
| Critical | Online payments, patient records | Seconds to minutes | Minutes to an hour |
| Important | Customer portal, order processing | Minutes to an hour | A few hours |
| Standard | Internal tools, reporting | Hours | Half a day |
| Low | Test environments, archives | A day or more | Days |
Promising a very small RPO and RTO to the business without checking whether the technology, network, and team can actually deliver them. Targets should come from measured tests, not wishes.
4Site Recovery Versus Backup: Not the Same Thing
Many beginners confuse disaster recovery with backup, but they solve different problems.
What Backup Does
Backup takes point-in-time copies of your data and keeps them for a long time, such as days, months, or years. Backup protects you when data is deleted by mistake, corrupted, or encrypted by ransomware, because you can go back to a clean earlier version. Restoring from backup usually takes longer, because the data must be rebuilt into a working system.
What Site Recovery Does
Site Recovery keeps a nearly current copy of your running servers in another location, ready to start quickly. It protects you when a whole location, system, or region fails and you need your applications running again in minutes or hours. However, because the copy is almost current, any corruption or deletion on the original is also quickly copied. Site Recovery is therefore not a replacement for backup.
Backup is like keeping dated photographs of your house in a safe: if someone paints the wall the wrong color, you can see exactly how it looked last year. Site Recovery is like having a second, identical house ready to move into if the first one is flooded. You need photographs for mistakes and the second house for catastrophes.
| Question | Backup | Site Recovery |
|---|---|---|
| Main purpose | Recover lost, deleted, or corrupted data | Keep applications running through site-level failures |
| Copy style | Point-in-time copies, kept long term | Continuous replication, short retention of recovery points |
| Speed of recovery | Slower, rebuild from copies | Faster, start prepared replicas |
| Protects against ransomware or accidental deletion | Yes, restore a clean earlier version | Limited, since changes replicate quickly |
| Protects against datacenter or region outage | Partly, if backups are stored elsewhere | Yes, designed for this |
Use both. Azure Backup and Site Recovery are separate services that work well together, covering mistakes and corruption on one side and large-scale outages on the other.
5Supported Scenarios
Site Recovery protects workloads wherever they run, as long as the target is Azure or another Azure region.
The Main Scenarios
Azure to Azure
Replicate Azure virtual machines from one Azure region to another, or between zones within a region, so a regional outage does not stop you.
VMware to Azure
Replicate VMware virtual machines running in your own datacenter into Azure, using an appliance installed on your network.
Hyper-V to Azure
Replicate Microsoft Hyper-V virtual machines from your datacenter into Azure using an agent on the Hyper-V hosts.
Physical Servers to Azure
Replicate physical servers, both Windows and Linux, into Azure, treating them like virtual machines after failover.
Think of a moving company that can pack a family’s belongings from an apartment, a townhouse, or a farmhouse, and unpack them all into the same safe warehouse. The starting place differs; the destination is always Azure.
Why Scenario Matters
The scenario decides what components you must set up. Azure-to-Azure is the simplest, because both ends are inside Azure and an extension is added to each virtual machine automatically. For VMware, Hyper-V, and physical servers, you install extra software in your own environment to collect and send the data, which later chapters explain.
Support for specific operating systems, disk types, and features changes with each release. Before designing around a scenario, check Microsoft’s support matrix for your exact versions, disk sizes, and configurations.
6The Core Building Blocks
Seven simple ideas explain almost everything: vault, replication policy, replicated item, recovery point, recovery plan, network mapping, and target settings.
Recovery Services Vault
Everything starts with a Recovery Services vault, an Azure container that holds your replication settings and tracks the state of everything being protected. It is the control center. For Azure-to-Azure protection, the vault is normally placed in the target region, the place you would recover into. The same type of vault is also used by Azure Backup, though backup and site recovery settings are kept separately inside it.
Replicated Item
Each server that you protect becomes a replicated item. The service records its current replication status, health, latest recovery point, and where it will start after failover.
Replication Policy
A replication policy is a set of rules that applies to a group of replicated items. It decides how long recovery points are kept and how often special, application-aware snapshots are taken. You create a policy once and apply it to many servers.
Recovery Point
A recovery point is a saved moment in a server’s history that you can recover to. Because data is copied continuously, the service stores a series of recovery points, so you can choose the most recent one or step back to an earlier one if the latest is not suitable.
Recovery Plan
A recovery plan groups servers together and says in what order they start, what scripts or manual steps happen along the way, and so on. It turns a pile of individual servers into a coordinated application recovery.
Network Mapping
A network mapping tells the service which network in the target location corresponds to each network in the source, so recovered servers land in the right place with sensible addresses.
Target Settings
For each replicated server you choose its target: the resource group, the network, the storage type for replica disks, and where applicable the availability zone or availability set the recovered server joins.
Picture an evacuation plan for a school. The control office is the vault. Each child on the list is a replicated item. The rules about how often attendance is taken are the policy. Each attendance check is a recovery point. The order in which classes leave the building is the recovery plan. The map showing which assembly point each class goes to is the network mapping.
flowchart TD
V["Recovery Services vault - control center"] --> P["Replication policy - retention and snapshot rules"]
V --> R1["Replicated item: web server"]
V --> R2["Replicated item: application server"]
V --> R3["Replicated item: database server"]
P --> R1
P --> R2
P --> R3
R1 --> RP["Recovery plan - order and steps"]
R2 --> RP
R3 --> RP
RP --> T["Target network, resource group, and settings"]
Name vaults, policies, and recovery plans after the application and the purpose, such as “orders-app-dr-plan”, so anyone can understand them quickly in the middle of an emergency.
7How Replication Works
Understanding the copying process explains recovery points, costs, and limits.
Initial Replication
When you first protect a server, the service must copy everything on its disks to the target location. This initial replication can take hours or longer, depending on how much data there is and how fast the network is. During this period the server is not yet recoverable. Once the first full copy exists, the service switches to copying only what changes.
Ongoing Replication
After the first copy, the service watches for changes to the server’s disks and sends them to the target in near real time. For Azure virtual machines, a small helper called the Mobility service runs inside the machine and captures writes. The changes first go to a temporary cache storage account in the source region, which acts like a loading dock, and are then moved to the target region where they update replica disks. These replica disks are the copies from which a recovered server will start.
Imagine copying a very large book by hand into a second notebook. First you copy the entire book, which takes a long time. After that, whenever the author adds or changes a sentence, you quickly add only that sentence to your copy. The loading dock is a small tray where changed sentences wait briefly before being added to the notebook.
sequenceDiagram
participant S as Source Server
participant M as Mobility Service
participant C as Cache Storage in Source Region
participant R as Replica Disks in Target Region
participant V as Recovery Services Vault
S->>M: Writes data to disk
M->>C: Sends captured changes
C->>R: Transfers changes to the target region
R->>R: Applies changes to the replica disks
R->>V: Reports health and latest recovery point
V->>V: Tracks RPO and replication status
Data Change Rate
A busy database that rewrites large amounts of data every second creates many changes to send. This rate is called the churn or data change rate. The service has limits on how much churn it can handle per disk and per virtual machine. If a server changes data faster than the network or limits allow, replication falls behind and the actual recovery point objective grows. Planning for churn is an important part of sizing a protection design.
What Is Not Replicated Automatically
Replication copies disk contents. It does not automatically copy everything around the server. Networking rules, load balancers, public addresses, firewall settings, and some configuration must be prepared in the target location in advance, ideally through automation templates, or the recovered server will start but nobody will be able to reach it.
Assuming that replicating the servers is the whole job. A recovered server with no network route, no name resolution, and no firewall access is technically running but practically useless. Prepare the surrounding environment too.
8Recovery Points and Consistency
Not every saved moment is equally safe to start from, so Site Recovery offers different kinds of recovery points.
Crash-Consistent Recovery Points
A crash-consistent recovery point captures the disk exactly as it would look if the machine had lost power at that instant. All the data that had been written to disk is there, but anything the applications were holding in memory, such as a half-finished database operation, is not. Most modern operating systems and databases can recover cleanly from such a state, much as they would after a sudden power cut. Crash-consistent points are generated frequently and are the default type.
Application-Consistent Recovery Points
An application-consistent recovery point is more careful. Before capturing, the service asks supporting applications, such as databases, to briefly finish what they are doing and write everything neatly to disk. The result is a clean, tidy snapshot that applications can start from without having to repair themselves. These snapshots take a bit more effort, so they are taken less often, typically every few hours according to the policy you choose.
A crash-consistent point is like taking a photograph of a busy kitchen mid-service: everything is exactly as it was, even a half-chopped onion on the board. An application-consistent point is like asking the cooks to finish the dish in hand and put everything in its place before the photograph. The second is tidier, but you cannot ask the cooks to stop every few seconds.
Crash-Consistent Points
- Taken frequently, giving a very small data loss window
- No effort required from applications
- Fine for most servers and many databases
Application-Consistent Points
- Cleaner start for databases and transactional applications
- Taken less often, so possible data loss is larger
- Requires support from the operating system and application
Recovery Point Retention
The policy decides how long recovery points are kept. A common default keeps them for roughly a day, giving you a rolling window of recent states to choose from. Longer retention gives more choice but increases storage cost. Because Site Recovery is not designed for long-term history, use backup for retention measured in weeks or months.
Choosing Which Point to Recover To
At failover time you can choose the latest processed point, which is the newest point already prepared and gives a fast start, the latest point, which processes all data received and takes slightly longer but loses the least data, or a specific earlier point. For multi-server applications there are also options to use a recovery point that is consistent across all servers in the group, so that, for example, the application server and the database server are recovered to the same moment.
| Choice | Speed | Data Loss | Best For |
|---|---|---|---|
| Latest processed | Fastest start | Slightly more than latest | Urgent outages where speed matters most |
| Latest | Slower, must process pending data | Smallest | When minimizing data loss is the priority |
| Earlier chosen point | Depends | Larger, by design | Recovering from a problem that began recently |
| Multi-server consistent point | Depends | Slightly larger | Applications spread across several servers |
9Failover, Test Failover, and Failback
The heart of the service is the ability to switch to the copy, practice that switch safely, and return afterward.
Test Failover: The Fire Drill
A test failover starts copies of your servers in the target location, but in an isolated network that is not connected to your live systems. Your real servers keep working and replication continues undisturbed. You check that servers start, applications work, and data looks right, and then clean up the test resources. Because it costs only the temporary compute and storage used during the test, you can run drills regularly. This is the single most valuable habit in disaster recovery.
Planned Failover
A planned failover is a deliberate, controlled switch when you know the primary site is going to be unavailable, for example before expected severe weather or a datacenter maintenance event. The primary servers are shut down cleanly first, so no recent data is lost. It is available in certain scenarios, such as those involving on-premises machines.
Unplanned Failover
An unplanned failover is the emergency version. The primary site has failed, and you tell the service to start the recovered servers now, accepting the chance of losing a few moments of data. The service shuts down the source servers if it still can, picks the chosen recovery point, creates virtual machines from the replica disks in the target location, and starts them.
Commit and Re-protect
After a failover, the recovered servers run in the target location. You then commit the failover, which finalizes the choice and deletes the other recovery points so the server uses the one it started from. Next, you re-protect the servers, which reverses replication direction so that the servers now running in the target location are copied back toward the original site. This prepares for failback and also protects you against a second failure.
Failback
When the original location is healthy, a failback moves the workload home again. The reversed replication has kept the original location’s copy up to date, so you perform another failover in the other direction, commit it, and re-protect to restore the original replication from the primary site to the secondary.
A test failover is a fire drill where everyone walks to the assembly point and then returns to their desks, with no real emergency. An unplanned failover is a real evacuation. Commit means agreeing that this is where we are staying for now. Re-protect is arranging for a second backup location in case the new one has trouble. Failback is moving back into the original building once it is repaired and safe.
Replicate
Servers run normally at the primary site while changes flow continuously to the replica disks.
Fail Over
When the primary fails, you start replicas in the secondary location from a chosen recovery point.
Commit
You confirm the failover so the recovered servers become the active ones.
Re-protect
Replication reverses so the new active site is protected by a copy at the original site.
Fail Back
When the original site is healthy, you switch back and restore the original direction of replication.
Forgetting to commit or re-protect after a failover. Without re-protection, your workload runs in the new location with no disaster recovery protection at all, a risky state if a second problem occurs.
10Recovery Plans: Conducting the Orchestra
Real applications are made of several servers, and recovery plans make sure they come back together correctly.
Why Order Matters
A typical business application has several layers. A database holds the data. An application server runs the logic and needs the database. A web server shows pages to users and needs the application server. If all three start at the same instant, the web server may start before the application server is ready, and the application server may fail to find the database. Starting them in the correct order, with pauses where needed, makes recovery smooth.
What a Recovery Plan Contains
A recovery plan is made of groups that start one after another. All servers inside one group start together. Between groups, and before or after them, you can add actions. An action can be a script that runs automatically, a manual step that pauses until a person confirms, or an automation runbook from Azure Automation that performs tasks such as attaching a public address or updating a load balancer. Recovery plans can be used for test failovers and real failovers alike, and the same plan can be reused for failback.
A conductor does not let every musician start at once. The strings begin first, then the woodwinds join, then the brass. A recovery plan is the conductor’s score: it says who plays first, who waits, and what cues to follow.
Group 1: Data Layer
Database servers start first and are given time to become ready.
Action: Check the Database
A script or a manual confirmation verifies that the database is healthy before moving on.
Group 2: Application Layer
Application servers start once the database is ready.
Group 3: Web Layer
Web servers start last, and an automation step connects the load balancer and public address.
Final Action: Announce Ready
A notification tells the team that the application has been recovered and is ready for final checks.
Tips for Good Recovery Plans
Include Manual Steps Where Needed
Some decisions, such as confirming data looks right before opening to customers, need a person. Add a manual action rather than trying to automate everything.
Automate Network Changes
Use runbooks to attach addresses, update load balancers, and change name records so the application is reachable immediately after servers start.
Keep One Plan Per Application
Group servers by application so you can recover one application without disturbing others, while larger plans can combine several applications in business order.
Version and Document Plans
Keep notes about why each step exists and review the plan whenever the application changes.
11Networking and Connectivity After Failover
A recovered server is only useful if people and other systems can actually reach it.
The Network Challenge
When a server starts in a new location, it lives in a different network. It may receive a different address, sit behind a different firewall, and need to find other servers, such as databases, through a different route. If an application depends on fixed addresses, those must be handled carefully. This is the part of disaster recovery most often forgotten, and the reason many recoveries stall even after the servers start.
Ways to Handle It
Pre-Built Target Network
Create the target virtual network, subnets, and security rules ahead of time, ideally matching the source layout, using templates so they are repeatable.
Network Mapping
Tell Site Recovery which target network matches each source network so servers land in the right place automatically.
Name-Based Access
Use names instead of fixed addresses for communication between systems, so changing locations does not break connections.
Traffic Redirection
Use a global traffic routing service or name records to send users to the recovered location when failover happens.
Hybrid Connectivity
For recovery of on-premises systems into Azure, plan a secure connection back to the office or datacenter so staff and other systems can reach the recovered servers.
Reserved Addresses
Where an application needs a stable address, reserve a matching one in the target ahead of time and assign it during recovery.
If your restaurant moves to the backup kitchen across town, the food can be cooked immediately, but customers will not come unless the phone number forwards to the new location and the delivery drivers know the new address. The kitchen is the servers; the phone forwarding is the network plan.
Use test failovers specifically to check connectivity: can users reach the application, can servers find each other, can the application reach the services it depends on, such as email or payment providers?
12Protecting On-Premises Servers: VMware, Hyper-V, and Physical
When the source is your own datacenter, a few extra components do the collecting and sending.
VMware and Physical Servers
For VMware virtual machines and physical servers, you deploy a replication appliance in your datacenter. This is a virtual machine that bundles several roles. It talks to the Azure service, discovers the machines to protect, receives change data from them, compresses and encrypts the data, and sends it to Azure storage. Each protected machine runs a small Mobility service agent that captures changes. The appliance acts like a collection depot that gathers parcels from every machine and ships them in bulk.
Hyper-V
For Hyper-V, you install a small provider and an agent on the Hyper-V hosts. Together they send changes from the virtual machines directly to Azure without needing a separate appliance machine, though hosts may be registered through a management server or directly, depending on your setup.
Imagine many small shops each needing to send goods to a distant warehouse. A local depot collects parcels from every shop, packs and seals them, and sends one organized shipment. The replication appliance is that depot.
Planning Considerations
| Topic | What to Plan |
|---|---|
| Network bandwidth | Enough upload capacity to send the initial copy and keep up with ongoing changes |
| Appliance sizing | Enough capacity for the number of machines and the amount of data change |
| Azure target setup | Target network, storage type, and resource group prepared in advance |
| Connectivity after failover | Secure link between office and Azure so staff can reach recovered servers |
| Failback path | Plan how data returns to the datacenter after the event is over |
Underestimating bandwidth. If your internet link cannot carry the daily data changes of the protected machines, replication falls behind and your real RPO grows without anyone noticing until it is tested. Measure change rates before committing to targets.
13Security and Access Control
Replicated copies hold the same sensitive data as the originals, so they need the same level of protection.
Protecting Data in Transit and at Rest
Data replicated to Azure travels over encrypted connections, and the replica disks are encrypted when stored. Azure virtual machines that use disk encryption can also be protected, and the service supports customer-managed encryption keys in many configurations, which keeps control of the keys with your organization. As a general principle, the copy in the second location should be protected at least as strongly as the original.
Roles for Disaster Recovery
Azure uses role-based access control, and there are built-in roles for this service. A reader role can view replication status without changing anything. An operator role can run failovers, test failovers, and related operations but cannot create or remove protection. A contributor role can manage the full configuration. Assigning these roles to groups lets you keep day-to-day monitors separate from the few people allowed to trigger real failovers.
Think of an emergency plan for a building. Many people may read the plan, a small trained group may sound the evacuation, and only the safety manager may rewrite the plan. You would not give everyone authority to order a full evacuation on a whim.
Use Groups for Roles
Assign reader, operator, and contributor roles to groups so changes in staff are easy to manage.
Limit Who Can Fail Over
Only a small, trained group should be able to trigger real failovers, and the decision process should be documented.
Protect the Replicas
Apply the same encryption, network rules, and monitoring to the target location as to the source.
Review Access Regularly
Check who holds recovery roles every few months and remove access that is no longer needed.
Make sure your emergency access does not depend on the failed site. If your identity systems or documentation live only in the primary location, you may be unable to start the recovery.
14Monitoring Replication Health
A recovery system that silently stops copying data gives false comfort, so health must be watched continuously.
What to Watch
The vault shows the health of each replicated item and its current state, such as protected, initial replication in progress, or needs attention. It also shows the latest available recovery point and the current RPO, so you can see how far behind each server is. Warnings appear when replication stalls, when the source cannot communicate, when disks exceed churn limits, or when the Mobility service needs an update.
Replication Health
Shows whether each server is healthy, warning, or in a critical state.
Current RPO
Tells you how much data you would lose if you failed over right now.
Latest Recovery Point
Confirms that new recovery points are still being created on schedule.
Failover Readiness
Indicates whether recent test failovers have been completed, helping track how fresh your last drill was.
Agent and Extension Status
Reveals when the helper software on a server is out of date or has stopped working.
Churn and Throughput
Shows whether data changes are exceeding what the replication path can handle.
A smoke detector with a dead battery gives you a comforting sense of safety and no actual protection. Monitoring replication health is checking the battery regularly, so you know the alarm will really work on the night you need it.
Alerts and Notifications
You can configure notifications by email and send monitoring data to Azure Monitor, so unhealthy replication triggers alerts to the right team. Combine these with routine reviews, such as a weekly check of any server whose replication is in a warning state.
Treating a warning as noise because the server still works. A replication warning often means your protection is quietly degrading. Investigate warnings promptly, since fixing them during calm days is much easier than during an emergency.
15Practicing Recovery: Drills That Build Confidence
The value of a disaster recovery plan is proven only by rehearsing it.
Why Drills Matter
Systems change constantly. A new server is added and not protected. A password expires. A firewall rule blocks a vital connection. A script refers to an address that no longer exists. Without regular testing, these small cracks grow until the day you need recovery, when you discover them under pressure. Regular drills expose problems while they are cheap to fix.
Levels of Testing
Basic Test: Do the Servers Start?
Run a test failover and confirm that each server boots, joins the right network, and shows recent data.
Application Test: Does the System Work?
Log into the recovered application in the isolated network and run real checks: sign in, search, place a test order, view reports.
Dependency Test: Does Everything It Needs Exist?
Verify that connected services, such as directories, email gateways, and external partners, are reachable from the recovered environment.
People Test: Can the Team Do It?
Have team members who did not build the plan run it from the documentation, to find unclear steps and missing access.
Timing Test: How Long Did It Take?
Record how long each step takes, so your stated recovery time objective is based on measurements rather than hopes.
Plan the Drill
Choose the application, the recovery point, and the success criteria. Tell stakeholders it is only a test.
Run a Test Failover
Use the recovery plan to start replicas in the isolated test network.
Validate
Check the application, data, and dependencies against the list you prepared.
Clean Up
Remove the test resources so you stop paying for them and leave the environment tidy.
Learn and Improve
Record what went wrong, fix the plan, and schedule the next drill.
Schedule drills on a calendar, at least a couple of times a year for important systems, and after any major change. Treat the results as a report card that leadership reviews.
16Understanding and Controlling Cost
Disaster recovery costs a steady small amount in calm times, and more only when you use it.
What You Pay For
Per-Server Protection Fee
A monthly fee for each protected server. Microsoft has historically offered a free period for each newly protected server, which you should confirm in current pricing.
Replica Storage
You pay for the disks that hold the copies in the target location, plus recovery point storage and the temporary cache.
Network and Data Transfer
Moving data between regions or from your datacenter can carry bandwidth charges, depending on the scenario.
Compute During Tests and Failovers
Virtual machines cost money only while they run, so drills and real failovers add compute charges for their duration.
It is like paying a small monthly fee to keep a spare apartment’s furniture in storage. You do not pay the full rent for the apartment unless you actually move in. Compute is the rent; storage and the protection fee are the storage unit.
Practical Ways to Manage Cost
Protect by Business Value
Protect the systems that matter most, and use backup alone for low-value systems.
Right-Size Replica Disks
Choose a suitable storage type for replicas, since many recovered servers can start on more economical disks and be upgraded later if needed.
Tune Retention
Keep only as many hours of recovery points as your recovery needs, since longer retention increases storage cost.
Clean Up After Tests
Always delete test failover resources when drills end so test servers do not keep running.
Review Protected Servers
Periodically remove protection from retired servers, which otherwise keep costing money for no benefit.
Cost-cutting that weakens recovery, such as skipping drills or removing network preparation, can turn a small saving into a large loss on the day of a disaster. Reduce waste, not readiness.
17Advantages and Trade-offs
No technology is perfect. Seeing both sides helps you decide where Site Recovery fits.
Advantages
- No second datacenter to build, with compute costs mainly during tests and failovers
- Supports Azure, VMware, Hyper-V, and physical servers
- Recovery plans orchestrate ordered, repeatable recovery
- Non-disruptive test failovers make regular drills practical
- Managed by Microsoft, with central monitoring and health reporting
- Works alongside Azure Backup for broader protection
Disadvantages / Trade-offs
- Recovery is not instant, as servers must start and applications warm up
- Replication is not backup, and corruption can replicate quickly
- Network, identity, and surrounding services still need separate planning
- High data change rates and limited bandwidth can increase data loss
- Support depends on specific operating systems and configurations
Comparing Approaches to Resilience
| Approach | Strengths | Weaknesses |
|---|---|---|
| Azure Site Recovery | Managed replication and orchestrated failover, pay mainly when used | Recovery takes time, requires planning of networks and dependencies |
| Active-active design across regions | Very fast or seamless recovery | Complex and costly, requires application redesign |
| Backup and restore only | Low cost, good protection against corruption | Slow recovery, larger data loss |
| Self-built secondary datacenter | Full control | High cost, constant maintenance, rarely tested |
Site Recovery fits applications that can tolerate minutes to hours of downtime but not days. Applications needing near-zero downtime usually require an active-active design built into the application itself, sometimes combined with Site Recovery for less critical components.
18Design Patterns and Anti-Patterns
Teams repeat the same successes and the same mistakes. Learn from both.
Patterns Worth Copying
Tier Your Applications
Sort applications by importance and set recovery targets per tier, so spending matches business impact.
Infrastructure as Code for the Target
Define target networks, security rules, and supporting services in templates, so the recovery environment is built consistently and is easy to rebuild.
One Recovery Plan Per Application
Group servers by application with correct ordering, automation, and manual checkpoints, and reuse the plan for drills and real events.
Regular, Measured Drills
Run test failovers on a schedule, measure the time taken, and feed lessons back into the plan.
Anti-Patterns to Avoid
Problem
Replication is configured once and never tested with a failover.
Why It’s Harmful
Hidden issues such as missing network rules, expired credentials, or unprotected servers stay hidden until a real disaster, when fixing them is slow and stressful.
Correct Approach
Run scheduled test failovers, validate applications and dependencies, measure recovery time, and fix every problem the drill reveals.
Problem
Site Recovery is treated as a replacement for backup.
Why It’s Harmful
Accidental deletion, data corruption, and ransomware changes replicate to the secondary copy within moments, leaving no clean version to return to.
Correct Approach
Use Azure Backup, or another backup solution, alongside Site Recovery, and keep backups with sufficient retention and protection.
Problem
Servers are replicated, but the supporting environment, such as networks, name resolution, identity, and load balancers, is not planned for the target location.
Why It’s Harmful
Recovered servers start but cannot communicate or be reached, so the application remains down despite successful replication.
Correct Approach
Pre-build the target environment with templates, map networks, automate traffic redirection in the recovery plan, and test connectivity in drills.
Problem
New servers are added to the environment without being added to replication, and nobody checks the list.
Why It’s Harmful
Over time, important systems quietly fall outside protection, and the disaster plan covers only part of the real application.
Correct Approach
Use policy and automation to ensure new servers are protected, and review the list of protected servers against inventory regularly.
19Real-World Use Cases
Across industries, teams use Site Recovery to turn frightening outages into manageable events.
Regional Outage Protection for a Web Shop
An online retailer replicates its web, application, and database servers to a second Azure region. When a regional problem occurs, it runs its recovery plan, redirects traffic, and resumes selling within its planned time target.
Moving Away From a Second Datacenter
A manufacturer replaces its rented backup datacenter by replicating on-premises VMware machines to Azure, paying mainly for storage until a real event or drill requires compute.
Compliance and Regular Testing
A financial company must show regulators that it can recover critical systems. It runs scheduled test failovers, records the results, and keeps evidence of successful recovery times.
Protecting Legacy Applications
A company with an older application that cannot easily be redesigned uses Site Recovery to replicate the entire server, gaining disaster protection without code changes.
Datacenter Migration
A team uses the same replication technology to move servers to Azure, replicating them, testing in an isolated network, and then performing a final cutover. The tooling for migration and disaster recovery is closely related.
Zone Failure Protection
A business running in a single Azure region replicates servers between availability zones within the region, protecting against the failure of one datacenter building while staying close for low delay.
20Best Practices and Common Mistakes
A short checklist that captures the lessons from earlier chapters.
Best Practices
Start With RPO and RTO
Agree on how much data loss and downtime each application can tolerate before choosing any technology.
Combine Backup and Replication
Use backup for mistakes and corruption, and Site Recovery for site-level failures.
Build Recovery Plans
Group servers by application, set the start order, and automate network changes with runbooks.
Prepare the Target Environment
Create networks, security rules, and supporting services in advance using templates.
Drill Regularly
Run test failovers on a schedule, measure results, and fix the issues they uncover.
Monitor and Alert
Watch replication health and current RPO, and respond quickly to warnings.
Document and Train
Keep clear instructions outside the primary site and train several people to run the plan.
Common Mistakes
Stating a recovery time objective without ever measuring one. Record real timings from drills and adjust expectations honestly.
Protecting an application’s servers but not the directory service, name servers, or shared tools it relies on. A recovered application that cannot sign users in is still down.
Failing to check that the target region has enough quota and available capacity for the virtual machine sizes you need. Verify quotas ahead of time and request increases early.
Forgetting to clean up after drills, which wastes money and can confuse later tests. Make cleanup part of every drill checklist.
21Getting Started: A Gentle Roadmap
You can begin with a small, low-risk application and grow your protection over time.
Inventory and Prioritize
List your applications and servers, sort them into tiers, and decide recovery targets for each.
Choose the Target
Pick the secondary region or zone, check that the services and sizes you need are available there, and confirm quotas.
Create the Vault and Policy
Set up a Recovery Services vault in the target location and a replication policy with sensible retention.
Enable Replication for a Pilot
Start with one non-critical application, let initial replication finish, and watch its health.
Build a Recovery Plan and Test
Create a plan, run a test failover, validate the application, and clean up.
Expand and Schedule Drills
Add more applications in priority order and put regular drills and health reviews on the calendar.
22Frequently Asked Questions
No. Backup keeps point-in-time copies for restoring lost or corrupted data over long periods. Site Recovery keeps near-current replicas to restart applications quickly after a site or region failure. Most organizations use both.
RPO, the recovery point objective, is how much data loss you can accept, measured in time. RTO, the recovery time objective, is how long you can be down before the application is running again.
Azure virtual machines between regions or zones, VMware virtual machines, Hyper-V virtual machines, and physical servers, with Azure as the recovery target for on-premises sources. Check the current support matrix for exact operating systems and configurations.
No. A test failover starts copies in an isolated network, and replication continues normally. You only pay for the test resources while they exist, so remember to clean them up.
Crash-consistent points capture the disk as if power were suddenly lost, and are taken frequently. Application-consistent points ask applications to tidy up first, giving a cleaner start for databases, but are taken less often.
Not for compute. You pay a protection fee per server and for replica storage while replicating. Virtual machine compute charges begin when you run a test or a real failover.
A recovery plan groups servers, sets the order in which they start, and adds actions such as scripts, manual steps, and automation runbooks, so a multi-server application recovers in a coordinated way.
You commit the failover, then re-protect the servers so replication runs in the reverse direction. Later, when the original location is healthy, you fail back and restore the original replication direction.
Only partly. It uses network mapping to place servers, but you need to prepare the target network, firewall rules, load balancers, and name resolution in advance, ideally with templates and recovery plan automation.
Common causes include communication problems, an outdated agent, data change rates exceeding limits, or insufficient bandwidth. Check the health details in the vault, resolve the cause, and watch the current RPO return to normal.
Regularly. Many organizations run drills at least a couple of times a year for important systems, and after significant changes to the application or environment. Regulated industries may require specific frequencies.
No. Recovery involves starting servers and warming up applications, so it takes minutes to hours. Applications that need near-zero downtime generally require an active-active design built into the application itself.
23Summary and Key Takeaways
Azure Site Recovery is a managed disaster recovery service that continuously copies your servers to a second location and helps you start them there when the first fails. A Recovery Services vault holds replication policies and tracks each replicated item, recovery points give you moments to return to, and recovery plans start servers in the right order with scripts and checkpoints. Test failovers let you rehearse in an isolated network, while failover, commit, re-protect, and failback move your workload out and back again. It protects Azure virtual machines, VMware and Hyper-V machines, and physical servers.
Success comes from starting with clear RPO and RTO goals, pairing replication with backup, preparing the target network and dependencies, monitoring replication health, and, above all, practicing recovery regularly. The service supplies the second kitchen; your preparation and drills decide whether the dinner service continues smoothly.
Key Takeaways
- It is disaster recovery as a service — Site Recovery replicates workloads to a second location and lets you fail over, then fail back, without building a second datacenter.
- RPO and RTO drive every decision — decide how much data loss and downtime each application can tolerate, and tier applications by business importance.
- Replication is not backup — use Azure Backup alongside Site Recovery to protect against deletion, corruption, and ransomware.
- Recovery plans orchestrate the return — group servers by application, start them in the right order, and automate network and traffic changes.
- Prepare the surroundings — networks, name resolution, identity, and capacity in the target location must be ready, or recovered servers will be unreachable.
- Test failovers build real confidence — drill regularly in an isolated network, measure timings, fix problems, and clean up afterward.
- Watch health and cost — monitor replication status and current RPO, protect by business value, tune retention, and remove protection from retired servers.