Azure VM Backup: Recovery Services Vault Policies, Immutability, Restore

To back up Azure virtual machines, create a Recovery Services vault in the same region as the VMs, assign a backup policy (Standard for daily or weekly backups, Enhanced for backups as often as every 4 hours), and enable protection so Azure Backup installs its extension and takes snapshots on schedule. Protect the backups by enabling vault immutability, then locking it once you are satisfied with your retention settings; soft delete is already enforced on every Recovery Services vault and keeps deleted backup data recoverable for 14 to 180 days. You restore individual files with File Recovery, or restore a new VM, disks only, or replacement disks from the Recover experience.

Who this is for and what you will have at the end

This guide is for administrators who run workloads on Azure VMs and need a backup setup that survives both accidental deletion and a compromised administrator account. It assumes you can create resources in the subscription that holds the VMs.

At the end you will have:

• A Recovery Services vault with the right storage redundancy, set before any item is protected.
• A backup policy that matches each VM's recovery point objective.
• Immutability enabled (and, when you are ready, locked) plus a soft delete retention period you chose deliberately.
• A tested restore of files and of a complete VM, with the commands to repeat it.

Prerequisites and design decisions

Decide these before you create anything, because two of them can't be changed later.

• Region. The vault must be in the same region as the VMs it protects. If you run VMs in several regions, create one vault per region.
• Storage redundancy. New vaults default to geo-redundant storage (GRS). Locally redundant (LRS) is cheaper, and zone-redundant (ZRS) keeps data in availability zones in the same region. You can't change the replication type once the vault contains backup items; you would have to create a new vault.
• VM agent. Azure Backup works through an extension on the Azure VM agent. Marketplace images already have the agent. Custom images and machines migrated from on-premises might need it installed manually; on Windows, the WaAppAgent.exe product version should be 2.6.1198.718 or later.
• Disk types. The Standard policy doesn't protect Premium SSD v2 or Ultra Disks, so those VMs need the Enhanced policy.
• Tag policies. Azure Backup creates a separate resource group for the restore point collection. If an Azure Policy assignment denies untagged resource groups, snapshot jobs can fail; see the troubleshooting section and the companion article on Azure Policy tag enforcement.

Standard versus Enhanced policy

With an hourly schedule, the last backup of the day is the one transferred to the vault. Also note that Azure Backup doesn't adjust schedules for daylight saving time, so you change policies manually when clocks change.

Step 1: Create the vault and set redundancy

1. In the Azure portal, search for Resiliency and open it.
2. On the Vault pane, select + Vault, choose Recovery Services vault, then Continue.
3. Enter the subscription, resource group, a vault name (2 to 50 characters, starting with a letter, letters, numbers and hyphens only) and the region that matches your VMs.
4. Select Review + create, then Create.
5. Before protecting anything, open the vault, go to Settings > Properties, select Update under Backup Configuration, pick GRS, LRS or ZRS, and select Save.

The same redundancy change from the Azure CLI:

az backup vault update \
  --name rsv-prod-weu \
  --resource-group rg-backup-prod \
  --backup-storage-redundancy ZoneRedundant

Step 2: Create a backup policy

The vault ships with a default policy that backs up once a day, keeps daily points for 30 days and keeps instant recovery snapshots for two days. For most production VMs you will want your own.

To create an Enhanced policy in the portal:

1. Open the vault and select Backup policies under Backup, then + Add.
2. On Select policy type, choose Azure Virtual Machine.
3. Set Policy subtype to Enhanced.
4. Under Backup schedule, choose Hourly, Daily or Weekly. For hourly, the defaults are a start time of 8 AM, every 4 hours, for a 24-hour duration.
5. Set Instant Restore retention (1 to 30 days). The maximum shrinks as the number of snapshots per day grows: the PowerShell guidance gives 17 days for a 4-hour schedule and 22 days for a 6-hour schedule.
6. Review the Retention range. Enhanced defaults are 180 days for daily points, 12 weeks for weekly, 60 months for monthly and 10 years for yearly.
7. Select Create.

Enhanced policies keep more snapshots, which costs more. Use them for VMs whose recovery point objective genuinely needs intra-day points.

Step 3: Enable protection and run the first backup

1. In Resiliency, select + Configure protection.
2. Set Resources managed by to Azure, Datasource type to Azure Virtual machines, Solution to Azure Backup, and select Continue.
3. On Start: Configure Backup, select the vault and Continue.
4. Choose your policy, then under Virtual Machines select Add and pick the VMs. Only VMs in the vault's region appear.
5. Select Enable backup.

To run the first backup immediately rather than waiting for the schedule, go to Resiliency > Protected items, filter on Azure Virtual machines, open the item's More (...) menu and select Backup Now, then choose how long to keep that point.

The same steps in PowerShell, using the vault ID rather than a vault context:

$vault = Get-AzRecoveryServicesVault -ResourceGroupName "rg-backup-prod" -Name "rsv-prod-weu"
$pol   = Get-AzRecoveryServicesBackupProtectionPolicy -Name "vm-enhanced-4h" -VaultId $vault.ID
 
Enable-AzRecoveryServicesBackupProtection -Policy $pol -Name "app01" -ResourceGroupName "rg-app-prod" -VaultId $vault.ID
 
# On-demand backup kept for 60 days
$container = Get-AzRecoveryServicesBackupContainer -ContainerType "AzureVM" -Status "Registered" -FriendlyName "app01" -VaultId $vault.ID
$item      = Get-AzRecoveryServicesBackupItem -Container $container -WorkloadType "AzureVM" -VaultId $vault.ID
$endDate   = (Get-Date).AddDays(60).ToUniversalTime()
$job       = Backup-AzRecoveryServicesBackupItem -Item $item -VaultId $vault.ID -ExpiryDateTimeUTC $endDate
 
Wait-AzRecoveryServicesBackupJob -Job $job -Timeout 43200 -VaultId $vault.ID

Read the job phases correctly

Each VM backup job has three phases: Snapshot, Transfer data to vault and Validate backup. The progress bar only tracks the transfer phase. A recovery point is only considered restorable after Validate backup succeeds, and the first transfer can take a long time for large disks. If the snapshot completes but the transfer fails, the job shows Completed with warning.

Step 4: Enable and lock immutability

An immutable vault blocks operations that could destroy recovery points before they expire. On a Recovery Services vault that means:

• Stop protection with delete data is blocked. You can still stop protection and retain data.
• Changes that reduce retention in a policy are blocked. Increasing retention and changing the schedule still work.
• Swapping an item to a policy with lower retention is blocked.

To enable it:

1. Open the vault and go to Properties > Immutable vault > Settings.
2. Select Enable vault immutability.
3. Choose Enable based on backup policy (the default, which keeps every point immutable for its full policy retention) or Enable for specific duration (a fixed number of days, after which points remain until normal expiry but can be deleted). With a specific duration, you can't reduce policy retention below that duration.
4. Select Apply.

Leave the vault in the enabled-but-unlocked state while you confirm that no team needs to shorten retention. When you are ready, return to the same page and lock it. Locking is irreversible, makes the vault use WORM storage where available, and also freezes the duration you chose. You can't lock immutability during vault creation.

# Enable (reversible)
az backup vault update --name rsv-prod-weu --resource-group rg-backup-prod --immutability-state Unlocked
 
# Later: lock (irreversible)
az backup vault update --name rsv-prod-weu --resource-group rg-backup-prod --immutability-state Locked

Enabling or disabling immutability needs Backup Contributor permissions on the vault. If the vault is protected by a Resource Guard, disabling immutability also requires access to that Resource Guard.

One cost detail to plan for: when you stop backups and choose to retain data as per policy, the last vaulted recovery point and the latest recovery point are retained indefinitely, and you have to delete them manually after the policy would have expired to stop the charges.

Step 5: Set soft delete retention

Soft delete is enforced by default on Recovery Services vaults and can't be disabled by any client or API version. When a backup item is deleted it moves to a soft-deleted state; deleted recovery points from retention reductions and deleted vaults behave the same way. The retention window defaults to 14 days and can be set from 14 to 180 days. The first 14 days are free; days beyond that are billed at regular backup rates.

Longer windows help when an intrusion is discovered late. Set it with:

az backup vault backup-properties set \
  --name rsv-prod-weu \
  --resource-group rg-backup-prod \
  --soft-delete-duration 60

To recover a soft-deleted VM backup, open the item and select Undelete. The item returns in the Stop protection with retain data state; backups don't restart until you select Resume backup. A deleted vault appears under Recovery Services vaults > Manage Deleted Vaults, where Undelete Vault brings it back; you then undelete its items separately and re-create managed identities and private endpoints.

Step 6: Restore files

File Recovery mounts a recovery point as iSCSI volumes on a machine you choose. It is intended for restores of 10 GB or less, at around 1 GB per hour.

1. Open the VM, select Backup, then File Recovery.
2. Under Select restore point, choose the point.
3. Select Download Executable (Windows) or Download Script (Linux, a Python script), and copy the password shown.
4. Run the file as an administrator (or with chmod +x and ./ on Linux) on a compatible machine and enter the password. The volumes appear with new drive letters or mount paths.
5. Copy the files, then select Unmount Disks in the portal.

The machine running the script needs outbound access to download.microsoft.com on port 443, to pod01-rec2.<geo-name>.backup.windowsazure.com on port 3260, and to DNS on port 53. Proxies often don't pass iSCSI, so run it from a machine with direct access. The script grants read-only access for 12 hours. File Recovery isn't supported for encrypted VM backups, and you shouldn't run the script on the source VM if it uses Storage Spaces, spanned or striped dynamic volumes, or Linux LVM or RAID arrays; use another machine with a compatible operating system.

Step 7: Restore a whole VM or its disks

1. In Resiliency, select Recover, set Datasource type to Azure Virtual machines, pick the protected item and select Continue.
2. Under Restore point, select a point.
3. Choose a restore type:
   • Create new > Create new virtual machine: builds a VM in the same region as the source, in the virtual network and subnet you pick.
   • Create new > Restore disks: restores managed disks plus a template you can deploy from the restore job with Deploy Template.
   • Replace existing > Replace disk/s: swaps the disks on the existing VM after taking a snapshot of the current state. Use it only when the point's Transfer data to vault phase completed.
4. Choose a Staging location storage account in the vault's region and select Restore.

The restored VM keeps the SKU it had when the recovery point was created. Cross Region Restore (to the paired region) and Cross Zonal Restore are also available, but only from vault-tier points, and Cross Zonal Restore requires a vault with ZRS or Cross Region Restore. For full region-level disaster recovery with lower recovery point objectives, Site Recovery is the better tool; see Azure-to-Azure disaster recovery with Site Recovery.

A disk restore in PowerShell:

$vault = Get-AzRecoveryServicesVault -ResourceGroupName "rg-backup-prod" -Name "rsv-prod-weu"
$item  = Get-AzRecoveryServicesBackupItem -BackupManagementType "AzureVM" -WorkloadType "AzureVM" -FriendlyName "app01" -VaultId $vault.ID
$rp    = Get-AzRecoveryServicesBackupRecoveryPoint -Item $item -StartDate (Get-Date).AddDays(-7).ToUniversalTime() -EndDate (Get-Date).ToUniversalTime() -VaultId $vault.ID
 
$restoreJob = Restore-AzRecoveryServicesBackupItem -RecoveryPoint $rp[0] `
  -StorageAccountName "stbackupstagingweu" -StorageAccountResourceGroupName "rg-backup-prod" `
  -TargetResourceGroupName "rg-app-restore" -VaultId $vault.ID
 
Wait-AzRecoveryServicesBackupJob -Job $restoreJob -Timeout 43200 -VaultId $vault.ID

Verification

• Resiliency > Jobs shows the first backup with all three phases succeeded.
• The vault's Properties page shows the redundancy you intended and the immutable vault state.
• az backup vault backup-properties show --name rsv-prod-weu --resource-group rg-backup-prod returns your soft delete duration.
• Try reducing a policy's retention on a test policy; with immutability enabled the save fails.
• A file restore and a full VM restore to an isolated resource group both complete, and the restored VM boots.

Troubleshooting

UserErrorRequestDisallowedByPolicy: An invalid policy is configured on the VM which is preventing Snapshot operation. A tag policy with a deny effect is blocking the resource group Azure Backup creates. Change the tag policy from deny to modify, or create the resource group yourself using Azure Backup's naming schema.

UserErrorUnableToOpenMount. The backup extension couldn't open a mount point. A common cause is a File Recovery session left open on a machine that is itself backed up; select Unmount Disks for that recovery point.

ExtensionFailedVssWriterInBadState: Snapshot operation failed because VSS writers were in a bad state. Run vssadmin list writers on the VM, restart the service behind any writer that isn't [1] Stable, check free disk space and memory, then retry.

VMRestorePointInternalError with IaaSBcdrExtension.exe faulting in the Application log. Antivirus is blocking the backup extension; exclude C:\Packages\Plugins\Microsoft.Azure.RecoveryServices.VMSnapshot and C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.RecoveryServices.VMSnapshot.

UserErrorInstantRpNotFound: Restore failed because the snapshot of the VM was not found. The point was never transferred to the vault and its snapshot has expired. Restore from another point.

UserErrorSkuNotAvailable: VM creation failed as VM size selected is not available. Use Restore disks and build the VM with a supported size.

Reducing policy retention fails. The vault is immutable. Increase retention instead, or, if the vault isn't locked and the change is approved, disable immutability first.

Checklist

• Vault created in the VMs' region with redundancy set before protecting items.
• Standard or Enhanced policy chosen per VM, with instant restore and retention matching the recovery point objective.
• First backup completed through Validate backup.
• Immutability enabled, tested, then locked.
• Soft delete retention set to a value longer than your likely detection time.
• File Recovery tested from a separate machine and the disks unmounted.
• Full VM restore tested into an isolated resource group.
• Tag policies reviewed so they don't block Azure Backup's resource group.

For the wider context of moving workloads to Azure, see the enterprise Azure cloud migration playbook.

References

• Back up Azure VMs in a Recovery Services vault
• Back up Azure VMs with the Enhanced policy
• Concept of immutable vault for Azure Backup
• Manage Azure Backup immutable vault operations
• Secure by default with soft delete for Azure Backup
• Configure and manage soft delete for Azure Backup
• Recover files and folders from Azure VM backup
• Restore VMs by using the Azure portal
• Back up and recover Azure VMs with PowerShell
• Troubleshoot backup errors with Azure VMs
• az backup vault
• az backup vault backup-properties