Hey there, IT champion! Ready to dive into the world of Azure Site Recovery (ASR)?
Native tools can be tricky to navigate and as companies and IT teams are relying on them to recover from operational failures as quickly (and as cheaply) as possible, you will need to fully understand the most optimal way to execute your business continuity plans.
In this guide, we’ll explore Azure Site Recovery (ASR), a solid service that will help you out when disaster strikes. We’ll explore its capabilities and provide many tips on how to improve on your disaster recovery objectives. In a previous blog we ran through the basics of how to use ASR and its 12 key features to help ensure business continuity. Here, we’ll take it a step further and provide real-world scenarios in which you would coordinate and set up replication between your sites. We also include quite a few PowerShell execution scripts which you are welcome to copy and paste. Lastly, we point out the service’s limitations and explain how N2W can be your go-to solution to have a ridiculously easy and extremely reliable DRaaS tool for your critical Azure workloads.
Let’s get started!
What Is Azure Site Recovery? Your First Line of Defense
Azure Site Recovery is often looked at as a cloud-native service, but it is possible to help manage on-premises, hybrid, and multicloud environments. It’s Microsoft’s disaster recovery as a service (DRaaS) solution that keeps your virtual machines and physical servers protected. Whether you’re replicating between Azure regions or from on-premises to Azure, ASR can provide the basics for your data replication processes.
But you know what they say – why settle for good when you can have great? As we walk through setting up ASR, we’ll point out N2W and the benefits it provides to take your data replication to the next level (read: much less complicated).
Step 1: Planning – Because Failing to Plan is Planning to Fail
First things first, let’s map out our strategy:
- Identify critical workloads: What absolutely can’t go down without causing a panic? These workloads might include:
- The main product database
- The payment processing system
- The customer-facing web application
- The inventory management system
- Set recovery objectives: Determine your RTO and RPO. (Recovery Time Objective and Recovery Point Objective, for the acronym-averse.)
- RTO: 4 hours for an e-commerce platform (meaning you need to be back up and running within 4 hours of a disaster)
- RPO: 15 minutes for the payment system (meaning you can’t afford to lose more than 15 minutes worth of transaction data)
- Assess network needs: How much bandwidth are we talking? If you’re replicating a 500GB database that changes by about 5% daily:
- Initial sync: 500GB
- Daily changes: 25GB
- Assuming an 8-hour replication window, you’d need at least 9 Mbps dedicated bandwidth for daily replication
- Calculate storage requirements: Always add a buffer – future you will thank present you. If your current environment consists of:
- 10 VMs, each 256GB in size
- 1TB of database storage
- 500GB of file storage
Your initial calculation might be 4TB. A good rule of thumb is to add a 20% buffer, so you’d want to plan for about 4.8TB of storage in your recovery site.
Now, while ASR gives you a solid foundation for these planning steps, N2W lets you get really granular. For instance, N2W allows you to set backup intervals as frequent as every 5 minutes consistently.
Step 2: Configuring Your Azure Environment – Setting the Stage
Time to roll up those sleeves and dive into the Azure portal:
1. Create a Recovery Services vault: This is ASR’s home base. All your replicated data and recovery plans will live here.
az backup vault create --name MyVault --resource-group MyRG --location eastus
2. Set up your network: Ensure your virtual networks are ready in both primary and recovery regions. Let’s say you already have vNets in East US (primary) and West US (recovery).
Here’s how you’d prepare them for ASR:
a. Verify the existing vNets:
az network vnet show --name PrimaryVNet --resource-group PrimaryRG
az network vnet show --name RecoveryVNet --resource-group RecoveryRG
b. Create subnets for ASR (if not already present):
az network vnet subnet create \\
--name ASR_Subnet \\
--resource-group PrimaryRG \\
--vnet-name PrimaryVNet \\
--address-prefix 10.0.1.0/24
az network vnet subnet create \\
--name ASR_Subnet \\
--resource-group RecoveryRG \\
--vnet-name RecoveryVNet \\
--address-prefix 10.1.1.0/24
c. Set up or verify VNet peering between the two regions:
az network vnet peering create \\
--name PrimaryToRecovery \\
--resource-group PrimaryRG \\
--vnet-name PrimaryVNet \\
--remote-vnet RecoveryVNet \\
--allow-vnet-access
az network vnet peering create \\
--name RecoveryToPrimary \\
--resource-group RecoveryRG \\
--vnet-name RecoveryVNet \\
--remote-vnet PrimaryVNet \\
--allow-vnet-access
d. Configure Network Security Groups (NSGs) to allow ASR traffic:
az network nsg create --name ASR_NSG --resource-group PrimaryRG --location eastus
az network nsg rule create \\
--name AllowASRTraffic \\
--nsg-name ASR_NSG \\
--priority 100 \\
--resource-group PrimaryRG \\
--access Allow \\
--protocol Tcp \\
--direction Inbound \\
--source-address-prefixes AzureSiteRecovery \\
--source-port-ranges "*" \\
--destination-address-prefixes "*" \\
--destination-port-ranges 443
Repeat this NSG creation for the recovery region as well.
3. Configure storage: Set up your storage accounts or managed disks. To set up a storage account, you could use the az storage command to creating a storage account in the recovery region.
az storage account create \
--name mystorageaccount \
--resource-group RecoveryRG \
--location westus \
--sku Standard_LRS \
--kind StorageV2
For managed disks, you typically don’t need to pre-create them. ASR will create them during failover based on the source disk configuration. However, if you want to pre-create a managed disk:
az disk create \
--name MyManagedDisk \
--resource-group RecoveryRG \
--location westus \
--size-gb 128 \
--sku Premium_LRS
💡 ASR makes this process straightforward, which is great. But if you’re looking for more control and flexibility, especially when it comes to managing backups across both Azure and AWS, N2W has got you covered.
For instance, while ASR requires you to manually set up and maintain these network configurations, N2W can automatically manage network settings across multiple cloud environments. This can be a real time-saver, especially in complex setups involving both Azure and AWS resources. Plus, N2W provides more granular control over your network configurations, ensuring that your disaster recovery setup perfectly matches your specific needs, even as they evolve over time.
Step 3: Implementing Replication – Making Copies, Staying Safe
Now for the main event – setting up replication:
- 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.
- Enable replication: Navigate to your Recovery Services vault and start the replication process.
- Choose your source and target: Where’s your data now, and where should it go in case of disaster?
- Select VMs to replicate: Pick the VMs you want to protect.
- Configure replication settings: Set up your replication policy, including snapshot frequency.
az site-recovery protection-container-mapping create \\\\
--resource-group MyRG \\\\
--vault-name MyVault \\\\
--name MyMapping \\\\
--protection-container MyContainer \\\\
--policy-name MyPolicy
ASR does a decent job here, but if you’re thinking, “I wish I could back up more frequently,” or “It’d be great to have more granular control,” that’s where N2W shines. With N2W, you can set up backups as frequently as every 5 minutes and enjoy file-level recovery without any agents.
Step 4: Creating Recovery Plans – Your Disaster Recovery Playbook
Recovery plans in ASR are like your disaster playbook. They allow you to group VMs and orchestrate a multi-tier application recovery. Let’s break it down:
1. Create a recovery plan:
In the Azure portal, you’d head to your Recovery Services vault > “Site Recovery” > “Recovery Plans” > “+ Recovery plan”.
Let’s say we’re creating a plan for an e-commerce application with a web tier, application tier, and database tier. You could also use the Azure CLI to create a recovery plan on a single line.
az site-recovery recovery-plan create \\
--name EcommerceRecoveryPlan \\
--resource-group MyRG \\
--vault-name MyVault
2. Add VMs to the plan:
This is where you’d select which VMs should be part of this recovery plan. You can organize VMs into groups to control the order of recovery.
Example:
- Group 1: Database servers (VM-DB1, VM-DB2)
- Group 2: Application servers (VM-APP1, VM-APP2)
- Group 3: Web servers (VM-WEB1, VM-WEB2)
az site-recovery recovery-plan update \\
--name EcommerceRecoveryPlan \\
--resource-group MyRG \\
--vault-name MyVault \\
--add-protected-items VM-DB1 VM-DB2 VM-APP1 VM-APP2 VM-WEB1 VM-WEB2
3. Customize the plan:
A default plan is typically never enough. If needed, you should also add scripts or manual actions to ensure everything gets backed up correctly. You can add these before or after each group.
Examples:
a. After Group 1 (databases), run a script to verify database integrity.
Invoke-Sqlcmd -Query "DBCC CHECKDB"
b. Before Group 2 (application servers), add a manual action to update DNS records.
Action: Update DNS A record for app.mycompany.com to point to new IP
c. After Group 2, run a script to start application services
Start-Service MyAppService
d. After Group 3 (web servers), run a script to test web server connectivity.
$result = Invoke-WebRequest -Uri 'http://localhost'
if ($result.StatusCode -eq 200) {
Write-Host "Web server is up!"
} else {
Write-Error "Web server is down!"
}
You could then add all of these customizations to the recovery plan via the Azure CLI:
az site-recovery recovery-plan update \\
--name EcommerceRecoveryPlan \\
--resource-group MyRG \\
--vault-name MyVault \\
--add-post-actions group-1 \\
'{"scriptUri": "https://mystorageaccount.blob.core.windows.net/scripts/check_db.ps1"}'
az site-recovery recovery-plan update \\
--name EcommerceRecoveryPlan \\
--resource-group MyRG \\
--vault-name MyVault \\
--add-pre-actions group-2 \\
'{"actionName": "Update DNS records", "description": "Update DNS A record for app.mycompany.com to point to new IP"}'
💡 ASR’s recovery plans are functional, but they can be a bit… basic. If you’re looking for more advanced orchestration, N2W offers Recovery Scenarios. These allow for intricate, sequential recovery processes across multiple resource types and even cloud providers.
Step 5: Testing – Because Hope is Not a Strategy
Testing is crucial in disaster recovery. Here’s how to do it with ASR:
1. Initiate a test failover:
Select your recovery plan and start a test failover. This creates a sandbox environment to test your recovery without affecting production or ongoing replication.
For example, let’s test our “EcommerceRecoveryPlan” using the Azure CLI:
az site-recovery recovery-plan test-failover start \\
--name EcommerceRecoveryPlan \\
--resource-group MyRG \\
--vault-name MyVault \\
--recovery-point Latest \\
--target-vnet TestFailoverVNet
2. Verify the test failover:
Make sure everything starts up and runs correctly. This involves checking each tier of your application.
For example, for a database tier, you could connect to the test failover VM-DB1 using Azure Bastion or VPN and run SQL queries to verify data integrity:
USE EcommerceDB;
SELECT COUNT(*) FROM Orders;
SELECT TOP 10 * FROM Products ORDER BY LastUpdated DESC;
For application tier services, you could connect to an app VM and check if the application services are running.
Get-Service MyAppService
Or, check application logs for any startup errors:
Get-Content "C:\MyApp\Logs\AppLog.txt" -Tail 20
For web tier VMs, you could test local connectivity to the application servers:
Test-NetConnection -ComputerName VM-APP1 -Port 8080
Or test the website from within the test failover network:
$result = Invoke-WebRequest -Uri http://VM-WEB1
$result.StatusCode
3. Clean up: Once you’re done, clean up your test environment.
az site-recovery recovery-plan test-failover cleanup \\
--name EcommerceRecoveryPlan \\
--resource-group MyRG \\
--vault-name MyVault
While ASR’s testing capabilities are good, they can be a bit cumbersome, especially when it comes to automating and scheduling regular tests. This is where N2W really shines.
With N2W, you can:
- Schedule automated recovery tests to run at regular intervals (e.g., weekly or monthly)
- Get detailed reports of each test, including performance metrics and any issues encountered
- Automatically rollback changes after tests, ensuring your production environment remains untouched
- Test recovery across both Azure and AWS environments in a single orchestrated process
N2W essentially turns your disaster recovery testing from a manual, time-consuming process into an automated, regular health check for your business continuity strategy.
Why Solutions like N2W Exist
There you have it – a guide to implementing Azure Site Recovery. It’s a solid service that’ll get you started on the path to robust disaster recovery. But remember, in the world of IT, good enough rarely is.
N2W takes the foundation that ASR provides and build upon it, offering features like super-frequent backups, file-level recovery without the hassle of agents, and reports that’ll make your inner data nerd jump for joy.
So, as you implement ASR, keep in mind how tools like N2W can elevate your disaster recovery strategy from “meeting requirements” to “exceeding expectations.” Your data (and your boss) will thank you!
Ready to take your disaster recovery to the next level? Give N2W a try and see the difference for yourself. After all, in the world of IT, it’s always better to be over-prepared than under-protected!
💡 If you’d like a copy of all the examples covered in this blog post, feel free to download this PowerShell script.
