How to Set Up Azure Site Recovery for Business Continuity

Every business depends on its IT systems. When those systems go down — whether from hardware failure, ransomware, natural disaster, or human error — the clock starts ticking. Every minute of downtime costs money, erodes customer confidence, and threatens the viability of the organisation itself. For UK businesses, the question is not whether a disaster will occur but when, and whether you will be prepared to recover.

Azure Site Recovery (ASR) is Microsoft's disaster recovery service that enables businesses to replicate their on-premises and cloud-based workloads to Azure, providing the ability to fail over to the cloud when disaster strikes and fail back when the primary site is restored. It transforms disaster recovery from an expensive, complex undertaking into a manageable, affordable service that UK SMEs can implement without building a secondary data centre.

This guide walks you through the key concepts, planning considerations, and implementation steps for setting up Azure Site Recovery to protect your business-critical systems.

Understanding Azure Site Recovery

Azure Site Recovery works by continuously replicating your servers and workloads to Azure. Think of it as maintaining a constantly updated copy of your critical systems in the cloud, ready to be activated at a moment's notice. When your primary systems fail, you initiate a failover, and your replicated systems come online in Azure within minutes, allowing your business to continue operating while the primary site is repaired.

Key Concepts

The Recovery Point Objective (RPO) defines how much data you can afford to lose, measured in time. An RPO of one hour means you accept losing up to one hour of data in a disaster. Azure Site Recovery supports RPOs as low as 25 seconds for continuous replication, meaning you lose no more than 25 seconds of data — far better than traditional backup-based recovery, which typically has RPOs of 24 hours.

The Recovery Time Objective (RTO) defines how quickly your systems must be back online after a disaster. Azure Site Recovery typically achieves RTOs of two to fifteen minutes, depending on the number and complexity of the workloads being recovered. Compare this to rebuilding a physical server from backup, which can take hours or days.

Planning Your Azure Site Recovery Deployment

Identify Critical Workloads

Not every system needs the same level of disaster recovery protection. Start by categorising your workloads by criticality. Your line-of-business applications, database servers, and file servers are likely tier one — they must be recovered immediately. Email and collaboration tools (if hosted on-premises) are tier two. Development environments, test servers, and archive systems are tier three and may not need ASR protection at all.

This tiering approach ensures you invest DR resources where they deliver the most value. Protecting every server equally is wasteful; protecting only the most critical systems is pragmatic and cost-effective.

Tier	Workload Examples	Target RPO	Target RTO	ASR Protection
Tier 1 (Critical)	ERP, CRM, databases, file servers	< 5 minutes	< 15 minutes	Continuous replication
Tier 2 (Important)	Email (on-prem), intranet, printing	< 1 hour	< 4 hours	Continuous replication
Tier 3 (Non-Critical)	Development, testing, archives	< 24 hours	< 24 hours	Backup only (no ASR)

Network and Bandwidth Requirements

Azure Site Recovery requires sufficient bandwidth to replicate your data to Azure. The initial replication copies all data from your on-premises servers to Azure storage, which can be substantial — a server with 500GB of data needs 500GB transferred to Azure. After the initial sync, only changes (delta replication) are transmitted, which is typically much smaller.

For a UK business with a 100Mbps internet connection, the initial replication of a 500GB server takes approximately 12 hours. Delta replication for a moderately active server typically requires 5-20Mbps of sustained bandwidth. Ensure your internet connection has sufficient headroom to handle replication traffic without impacting business operations. Many businesses schedule the initial bulk replication during evenings or weekends to avoid daytime bandwidth contention.

Implementation Steps

Step 1: Set Up the Azure Environment

Create a Recovery Services vault in Azure, selecting a UK region (UK South or UK West) for data residency compliance. The vault is the central management point for all your ASR-protected workloads. Configure the vault's replication policy, specifying the recovery point retention period and application-consistent snapshot frequency.

Step 2: Deploy the Configuration Server

For protecting on-premises VMware or physical servers, deploy the ASR configuration server on a dedicated on-premises virtual machine. This server coordinates communication between your on-premises environment and Azure, manages replication, and handles failover orchestration. For Hyper-V environments, the Azure Site Recovery Provider is installed directly on your Hyper-V hosts.

Step 3: Enable Replication

Select the servers you want to protect and enable replication. ASR installs the Mobility service agent on each protected server, which captures disk writes and transmits them to Azure. The initial replication begins automatically, copying the full disk contents to Azure storage. Monitor the replication progress through the Azure portal — initial sync can take hours to days depending on data volume and bandwidth.

Step 4: Create Recovery Plans

Recovery plans define the order in which your servers are brought online during a failover. You might configure your domain controller to start first, followed by database servers, then application servers, then web servers. Recovery plans can include custom scripts — for example, updating DNS entries or starting specific services — that run automatically during failover.

Testing Your Disaster Recovery

A disaster recovery plan that has never been tested is not a plan — it is a hope. Azure Site Recovery includes a test failover feature that allows you to spin up your replicated servers in an isolated Azure network without affecting your production environment or replication. This means you can test your disaster recovery at any time without risk or disruption.

Schedule test failovers at least quarterly. During each test, verify that servers start in the correct order, applications function correctly, data is intact, and users can connect to the recovered environment. Document the results and address any issues discovered. The NCSC recommends regular DR testing as part of its resilience guidance for UK organisations.

Failover and Failback Procedures

When disaster strikes, initiating failover is straightforward. From the Azure portal, select the recovery plan and click "Failover." Azure spins up virtual machines from the replicated data, executes any custom scripts in the recovery plan, and brings your systems online in the cloud. Users connect to the Azure-hosted systems — typically via VPN or Azure Virtual Desktop — and continue working while the primary site is repaired.

Failback — returning operations to the primary site once it is restored — follows a similar process in reverse. ASR replicates changes made during the failover period back to the on-premises servers, and when synchronisation is complete, you execute a planned failover to move operations back to the primary site.