Azure Site Recovery (ASR) is a powerful disaster recovery service that ensures your business-critical workloads remain available during outages. In this tutorial, we’ll walk through setting up ASR from scratch using the Azure CLI. By the end, you’ll have a robust disaster recovery solution in place, ready to protect your Azure VMs.
Prerequisites
Before we dive in, make sure you have:
- An Azure subscription
- Azure CLI installed and configured
- Two Azure regions selected (source and target)
- Azure VMs you want to protect
Let’s get started!
Step 1: Install the Azure CLI ASR Extension
First, we need to install the Azure Site Recovery extension for the Azure CLI:
az extension add --name site-recovery
The Azure CLI uses extensions to add functionality. This command installs the Site Recovery extension, which provides the necessary commands to manage ASR through the CLI. Without this extension, you won’t have access to the ASR-specific commands we’ll be using in this tutorial.
Pro Tip: Keep your Azure CLI and extensions up to date to ensure you have access to the latest features and bug fixes. Check the Azure CLI documentation for update instructions.
Step 2: Create Resource Groups
We’ll need resource groups in both the source and target regions:
# Source resource group
az group create --name source-rg --location eastus
# Target resource group
az group create --name target-rg --location westus
Resource groups are logical containers for Azure resources. We create two: one in the source region (where your original VMs are located) and one in the target region (where your VMs will be replicated). This separation allows for easier management and billing of resources in each region.
Step 3: Create a Recovery Services Vault
The Recovery Services vault is where your backup and site recovery data is stored:
az recovery-services vault create \
--name myRecoveryVault \
--resource-group target-rg \
--location westus
The Recovery Services vault is a critical component of ASR. It stores all the replication data, recovery points, and configuration information. We create this in the target region because that’s where our replicated data will reside. The vault acts as a central management point for all your disaster recovery operations.
Best Practice: Name your resources descriptively. A naming convention like <company>-<environment>-<resource-type>-<region> can be helpful. Learn more about Azure naming conventions.
Step 4: Set Vault Context
To perform operations on the vault, we need to set its context:
az site-recovery vault set \
--vault-name myRecoveryVault \
--resource-group target-rg
This command sets the context for subsequent ASR operations. It tells the Azure CLI which vault to use for the commands that follow. This is similar to changing directories in a file system – we’re essentially “moving into” the vault we just created.
- Use Lifecycle Policies to Save Money: Set up lifecycle policies to move old backups to cheaper storage options like Amazon S3 Glacier. This can help you save a lot of money on storage costs.
- Back Up to Different Regions and Accounts: Make your disaster recovery plan stronger by copying backups to different AWS regions or accounts. This protects your data from region-specific problems and security issues.
- Automate Your Backup to Reduce RTO: Use AWS Backup to set up frequent backup intervals. Automating backups every hour or even every few minutes ensures you can recover data quickly, minimizing downtime.
- Tag Your Resources for Easy Management: Tags help you quickly identify and group related backups, making it easier to manage them and to monitor costs. This can also simplify reporting and compliance checks.
- Test Your Disaster Recovery Plan Regularly: Automate DR drills to check your backup and recovery processes. Make sure your backups work and that you can restore data quickly to find and fix any potential problems.
Step 5: Create a Replication Policy
Next, we'll create a [replication policy](https://learn.microsoft.com/en-us/azure/site-recovery/azure-to-azure-how-to-enable-replication) that defines how often recovery points are created:
az site-recovery replication policy create \
--name myReplicationPolicy \
--vault-name myRecoveryVault \
--resource-group target-rg \
--recovery-point-retention-in-minutes 24*60 \
--app-consistent-frequency-in-minutes 60
The replication policy is crucial as it determines the frequency of replication and how long recovery points are retained. In this example, we’re defining how frequently application-consistent snapshots are taken (app-consistent-frequency-in-minutes 60) and keeping them for 24 hours (recovery-point-retention-in-minutes 24*60). This allows you to restore your VM to any hourly state within the last day.
N2WS Advantage: While Azure Site Recovery offers hourly recovery points, N2WS provides backup intervals as frequent as every five minutes. This dramatically reduces your potential data loss in a disaster scenario. Learn more about N2WS’s backup frequency options.
Step 6: Create a Protection Container
Protection containers help organize your protected items:
az site-recovery protection-container create \
--name myProtectionContainer \
--vault-name myRecoveryVault \
--resource-group target-rg \
--fabric-name myFabric
A protection container is a logical grouping of VMs that you want to protect. The ‘fabric’ refers to the Azure infrastructure in a specific region. This command creates a container within the Azure fabric of your source region.
Step 7: Create a Protection Container Mapping
This mapping links the protection container to the replication policy:
az site-recovery protection-container-mapping create \
--name myContainerMapping \
--vault-name myRecoveryVault \
--resource-group target-rg \
--fabric-name myFabric \
--protection-container myProtectionContainer \
--policy-name myReplicationPolicy
This step connects the dots between your protection container and your replication policy. It tells ASR which policy to apply to the VMs in this container. This mapping allows you to have different replication settings for different groups of VMs if needed.
Step 8: Prepare the Infrastructure
Before we can replicate VMs, we need to prepare the infrastructure:
az site-recovery prepare-infrastructure \
--vault-name myRecoveryVault \
--resource-group target-rg \
--source-vm-id "/subscriptions/<subscription-id>/resourceGroups/source-rg/providers/Microsoft.Compute/virtualMachines/myVM" \
--target-resource-group target-rg \
--target-vnet-id "/subscriptions/<subscription-id>/resourceGroups/target-rg/providers/Microsoft.Network/virtualNetworks/myTargetVNet"
Replace <subscription-id> with your actual subscription ID.
This command sets up the necessary resources in your target region to receive the replicated VM. It creates network interfaces, storage accounts, and other required resources. The source-vm-id specifies which VM you’re protecting, and the target-vnet-id defines where the replicated VM will be placed in the target region.
Step 9: Enable Replication for a VM
Now we can enable replication for our VM:
az site-recovery replicate \
–vault-name myRecoveryVault \
–resource-group target-rg \
–vm-id “/subscriptions//resourceGroups/source-rg/providers/Microsoft.Compute/virtualMachines/myVM” \
–target-resource-group target-rg \
–target-vnet-id “/subscriptions//resourceGroups/target-rg/providers/Microsoft.Network/virtualNetworks/myTargetVNet”
This is where the actual replication begins. This command tells ASR to start replicating the specified VM to the target region. It uses the infrastructure and policies we set up in previous steps. The initial replication may take some time depending on the size of your VM and your network speed.
az site-recovery replicate \
--vault-name myRecoveryVault \
--resource-group target-rg \
--vm-id "/subscriptions/<subscription-id>/resourceGroups/source-rg/providers/Microsoft.Compute/virtualMachines/myVM" \
--target-resource-group target-rg \
--target-vnet-id "/subscriptions/<subscription-id>/resourceGroups/target-rg/providers/Microsoft.Network/virtualNetworks/myTargetVNet"
N2WS Feature: While Azure Site Recovery requires you to set up replication for each VM individually, N2WS allows you to create policies that automatically protect new VMs based on tags. This can save significant time in large environments.
Step 10: Monitor Replication Status
You can check the replication status with:
az site-recovery replication-protected-item list \
--vault-name myRecoveryVault \
--resource-group target-rg
This command provides a list of all items being replicated and their current status. It’s crucial to monitor this to ensure your VMs are properly protected. You can use this to check the progress of the initial replication and to verify ongoing replication health.
Step 11: Perform a Test Failover
Once initial replication is complete, it’s crucial to perform a test failover.
az site-recovery test-failover \
--vault-name myRecoveryVault \
--resource-group target-rg \
--recovery-plan myRecoveryPlan \
--test-network-id "/subscriptions/<subscription-id>/resourceGroups/target-rg/providers/Microsoft.Network/virtualNetworks/myTestVNet"
This example assumes you already have a recovery plan set up. For a single VM, you can perform a test failover without a recovery plan.
A test failover allows you to verify your disaster recovery setup without impacting your production workloads. It creates a copy of your VM in the target region using the latest recovery point. This lets you confirm that applications will work correctly in a real failover scenario. The test-network-id specifies an isolated network for the test to avoid any conflicts with your production environment.
N2WS Advantage: N2WS’s Recovery Scenarios feature allows you to automate and orchestrate complex failover processes, including application dependencies. This ensures your entire application stack, not just individual VMs, recovers correctly.
Step 12: Clean Up Test Failover
After verifying the test failover, clean it up:
az site-recovery test-failover-cleanup \
--vault-name myRecoveryVault \
--resource-group target-rg \
--recovery-plan myRecoveryPlan
This step is crucial for maintaining a clean environment and avoiding unnecessary costs. It removes the test VMs and networks created during the test failover. Always perform this cleanup after you’ve completed your failover testing to ensure you’re not continuing to replicate or maintain unnecessary resources.
Conclusion
Congratulations! You’ve successfully set up Azure Site Recovery using the Azure CLI. Your VMs are now protected and ready for disaster recovery scenarios. Remember to regularly test your failover process to ensure it works as expected when you need it most.
While Azure Site Recovery provides robust disaster recovery capabilities, tools like N2WS can complement and enhance your overall backup and recovery strategy. N2WS offers features like:
- More frequent recovery points (as often as every 60 seconds)
- Automated policy-based protection
- Advanced orchestration with Recovery Scenarios
- Granular file-level recovery without the need for agents
- Comprehensive backup reporting and management
Consider exploring N2WS to take your Azure backup and disaster recovery to the next level. With N2WS, you can ensure even greater data protection and easier management of your backup and recovery processes.
Remember, in the world of disaster recovery, it’s not just about having a plan – it’s about having a plan you can trust and execute flawlessly when it matters most. Regular testing and continuous improvement of your disaster recovery strategy are key to true business resilience.
To learn more about how N2WS can enhance your Azure backup and recovery strategy, visit the N2WS Azure Backup page.
