Azure / Guide 8
Backup and recovery
Azure Backup for VMs, protecting backups from ransomware, restores, and Site Recovery.
Backups only count if they restore. This guide covers Azure Backup for VMs, the settings that protect backups from ransomware and mistakes, restores, and where Azure Site Recovery fits.
Backup versus disaster recovery
| Azure Backup | Azure Site Recovery | |
|---|---|---|
| Protects against | Deletion, corruption, ransomware, "I need yesterday's version" | Losing a whole region or datacenter |
| How | Point-in-time copies kept for days to years | Continuous replication to another region |
| Recovery point | Last backup (usually daily) | Minutes |
| Recovery time | Hours (restore a VM or files) | Minutes to fail over |
Most workloads need backup. Business-critical ones need both.
Find VMs that aren't protected
Before anything else, check coverage. Get-AzBackupCoverage.ps1 lists every VM in every subscription and whether Azure Backup protects it:
.\Get-AzBackupCoverage.ps1
New VMs are the usual gap. An Azure Policy such as Configure backup on virtual machines with a given tag to an existing recovery services vault closes it automatically.
Set up Azure Backup for VMs
- Create a Recovery Services vault in the same region as the VMs, in a management subscription or resource group.
- Choose storage redundancy before the first backup (it can't be changed afterwards): geo-redundant (GRS) for production, with cross-region restore turned on so you can restore in the paired region.
- Create backup policies: schedule and retention (for example daily, kept 30 days, plus monthly kept 12 months). Use the Enhanced policy type where available; it supports several backups a day and is required for Trusted Launch VMs.
- Enable backup on the VMs:
$vault = Get-AzRecoveryServicesVault -ResourceGroupName rg-notes-test -Name rsv-notes-test
$policy = Get-AzRecoveryServicesBackupProtectionPolicy -Name 'DefaultPolicy' -VaultId $vault.ID
Enable-AzRecoveryServicesBackupProtection -Policy $policy -Name vm-notes-test-01 `
-ResourceGroupName rg-notes-test -VaultId $vault.ID
Take an on-demand backup (for example before a risky change):
$container = Get-AzRecoveryServicesBackupContainer -ContainerType AzureVM -FriendlyName vm-notes-test-01 -VaultId $vault.ID
$item = Get-AzRecoveryServicesBackupItem -Container $container -WorkloadType AzureVM -VaultId $vault.ID
Backup-AzRecoveryServicesBackupItem -Item $item -VaultId $vault.ID
Protect the backups themselves
Attackers go after backups first. Turn these on:
- Soft delete: deleted backup data is kept for a period (14 days by default, longer with enhanced soft delete) and can be recovered. Make it "always on" so it can't be switched off.
- Immutable vault: prevents backup data from being deleted or retention being shortened before it expires. Lock immutability once you're sure of your policies.
- Multi-user authorization with a Resource Guard: critical operations (disabling soft delete, reducing retention) need approval from a second person in a different subscription.
- A delete lock on the vault's resource group, and tightly limited Backup Contributor access.
Watch for failed backups
Get-AzRecoveryServicesBackupJob -VaultId $vault.ID -Status Failed -From (Get-Date).AddDays(-7).ToUniversalTime() |
Select-Object WorkloadName, Operation, Status, StartTime, @{n='Error';e={$_.ErrorDetails.ErrorMessage}}
Better still, set up alerts. Azure Backup sends built-in alerts through Azure Monitor; route them to an action group that emails or tickets the team. Azure Business Continuity Center (the successor to Backup center) shows backup and Site Recovery status across all vaults in one place.
Restoring
Azure Backup offers several ways back, depending on what went wrong:
| Need | Restore option |
|---|---|
| A few files | File recovery: mounts a recovery point as a drive so you can copy files out |
| A VM back as it was | Replace existing disks |
| A copy alongside the original | Create new VM from a recovery point |
| Full control (new network, different settings) | Restore disks, then build a VM from them |
Test restores on a schedule
Pick one VM per critical application each quarter, restore it into an isolated network, check the application starts and the data is there, then delete the copy. Write down how long it took; that's your real recovery time, not the one in the design document.
Beyond VMs
- Azure Files: Azure Backup takes share snapshots on a schedule.
- Blob storage: turn on soft delete, versioning and point-in-time restore, or use Azure Backup for blobs.
- SQL Server in a VM: use Azure Backup's SQL workload backup for log backups and point-in-time restore, not just VM backups.
- Azure SQL Database and managed databases have automatic backups built in; set the retention you need, including long-term retention.
Disaster recovery with Azure Site Recovery
For applications that must survive a regional outage, Azure Site Recovery replicates VMs to another region.
- Group VMs that fail over together into recovery plans, with scripts for the steps in between (DNS changes, starting services in order).
- Run a test failover into an isolated network at least twice a year. It doesn't affect production or replication.
- Remember everything the VMs depend on: domain controllers, DNS, firewalls and connectivity in the recovery region.