Back up and restore Azure virtual machines with Azure Backup

radio_button_uncheckedshort_text1. Design for a tested VM recovery outcome

A company runs critical Windows and Linux virtual machines in Azure and needs proof that a corrupted or deleted server can be recovered. The administrator must select an appropriate protection model, enable scheduled and on-demand backups, verify jobs, restore the required scope, and test the complete business continuity and disaster recovery (BCDR) runbook.

This chapter assumes basic knowledge of Azure Virtual Machines and managed disks. The optional lab uses an Azure subscription and creates billable resources, so use a sandbox when available and remove the lab resource group after validation.

• Identify where Azure Backup fits among availability, replication, and disaster-recovery services.
• Explain VM snapshots, consistency levels, Recovery Services vaults, policies, tiers, encryption, and the backup data path.
• Protect Windows and Linux VMs through the Azure portal and Azure CLI, then monitor configuration and backup jobs.
• Choose among whole-VM, disk, original-location, alternate-location, file-level, cross-region, cross-subscription, and cross-zone recovery.
• Perform a controlled disk-replacement exercise and verify every restore subtask.

radio_button_uncheckedshort_text2. Separate backup, availability, and disaster recovery

Azure Backup preserves point-in-time copies of stateful data so an administrator can move backward after deletion, corruption, ransomware, or an unwanted change. Azure Site Recovery continuously or near-continuously replicates supported machines and orchestrates failover to another location. Availability zones reduce exposure to localized datacenter failures while the application continues running.

The decision also depends on application criticality, RPO, RTO, retention, operational complexity, and cost. Backup and Site Recovery are complementary; neither substitutes for application-level high availability by itself.

radio_button_uncheckedshort_text3. Recognize Azure Backup capabilities and supported scenarios

Azure Backup is an Azure-managed protection service. For supported workloads, it removes the need to deploy a separate backup storage estate, offers self-service backup and restore, manages capacity, and centralizes policies, jobs, recovery points, security, and reporting.

Vault backup storage can use locally redundant storage (LRS), zone-redundant storage (ZRS), or geo-redundant storage (GRS), subject to workload, region, and configuration support. Choose redundancy before protection begins because later changes can be restricted.

radio_button_uncheckedshort_text4. Understand VM backup architecture and the Recovery Services vault

Azure VM backup coordinates a point-in-time snapshot of the selected managed disks and transfers protected data to service-managed storage associated with a Recovery Services vault. The vault is a management entity: it organizes policies, protected items, recovery points, jobs, alerts, security, and restore actions. You choose the vault rather than creating the underlying backup storage accounts yourself.

The vault must be compatible with the VM location and becomes an Azure RBAC boundary. Vault backup data is kept in infrastructure and fault domains separated from the source. A locally retained snapshot enables rapid operational recovery, while a vaulted copy provides longer retention and stronger isolation.

radio_button_uncheckedshort_text5. Distinguish application, file-system, and crash consistency

For Windows, the VMSnapshot extension coordinates with VSS. For Linux, VMSnapshotLinux provides VM integration and administrators own the correctness of application scripts. A VM-level VSS copy does not replace workload backup when database-level log recovery or second-level point-in-time recovery is required.

radio_button_uncheckedshort_text6. Choose Standard or Enhanced VM backup policy and its tiers

A VM backup policy defines when protection runs and how long each recovery-point class survives. Standard policy supports daily or weekly schedules. Enhanced policy supports multiple backups per day, intervals as frequent as every four hours, longer configurable snapshot retention, managed-disk features, and broader support for newer VM and disk capabilities.

A snapshot-tier recovery point is available as soon as the snapshot succeeds and supports Instant Restore. After transfer, its type becomes snapshot and vault. Local snapshots improve RTO but incur snapshot storage cost. Vault-tier data provides longer retention and isolation. Instant Restore cannot be disabled, but retention can be reduced to the supported minimum.

Selective disk protection is useful when only specific data disks are critical, or when a database-aware solution protects the application and VM backup only needs the operating-system disk. Document excluded disks so a restore does not produce an incomplete machine.

radio_button_uncheckedshort_text7. Follow the VM backup process from trigger to vault

1. Azure Backup starts the job according to policy or an on-demand request.
2. For agent-based application or file-system consistency, the first running-VM backup installs VMSnapshot on Windows or VMSnapshotLinux on Linux through the Azure VM agent. Supported agentless crash-consistent protection does not require the guest extension.
3. The extension coordinates VSS on Windows or the Linux snapshot framework, and the service creates a point-in-time disk snapshot.
4. A snapshot recovery point becomes available locally for Instant Restore.
5. Disks are processed in parallel. After the initial protected state, only changed blocks are identified and transferred to the vault.
6. Transfer can continue for hours at peak time; a daily VM backup normally completes in less than 24 hours, while the initial copy or a newly added disk can take longer.
7. The vault records the recovery point, retention, job state, and restore metadata. The current policy keeps protection running until it is explicitly changed or stopped.

Schedule different VMs at staggered times, monitor disk churn and extension health, and avoid overloaded target storage during restores. Customer-managed keys can protect supported vault data, while Storage Service Encryption and Azure Disk Encryption support protect disks and encrypted VMs according to their respective support matrices.

radio_button_uncheckedshort_text8. Lab: protect Windows and Linux VMs through portal and CLI

The source exercise proves that both Windows and Linux Azure VMs can be protected. The following equivalent lab uses neutral resource names and current navigation. Commands create billable resources; review current image availability, region quotas, security defaults, and prices before running them.

LAB_RG=$(az group create --name rg-az104-backup-lab --location westus2 --query name -o tsv)

az network vnet create \
  --resource-group "$LAB_RG" \
  --name vnet-az104-backup \
  --address-prefixes 10.20.0.0/16 \
  --subnet-name snet-workloads \
  --subnet-prefixes 10.20.1.0/24

az vm create \
  --resource-group "$LAB_RG" \
  --name vm-win-backup-lab \
  --image Win2022Datacenter \
  --size Standard_DS1_v2 \
  --admin-username azureadmin \
  --admin-password '<strong-password>' \
  --vnet-name vnet-az104-backup \
  --subnet snet-workloads \
  --public-ip-sku Standard

az vm create \
  --resource-group "$LAB_RG" \
  --name vm-linux-backup-lab \
  --image Ubuntu2204 \
  --size Standard_DS1_v2 \
  --authentication-type ssh \
  --generate-ssh-keys \
  --vnet-name vnet-az104-backup \
  --subnet snet-workloads \
  --public-ip-sku Standard

If the CLI reports that a security profile or image is invalid, check the current image offer, regional support, subscription feature registrations, and explicitly supported security type. Do not blindly repeat an old preview-registration command from a historical lab.

az backup vault create \
  --resource-group "$LAB_RG" \
  --location westus2 \
  --name rsv-az104-backup-lab

az backup protection enable-for-vm \
  --resource-group "$LAB_RG" \
  --vault-name rsv-az104-backup-lab \
  --vm vm-win-backup-lab \
  --policy-name EnhancedPolicy

az backup job list \
  --resource-group "$LAB_RG" \
  --vault-name rsv-az104-backup-lab \
  --output table

az backup protection backup-now \
  --resource-group "$LAB_RG" \
  --vault-name rsv-az104-backup-lab \
  --container-name vm-win-backup-lab \
  --item-name vm-win-backup-lab \
  --backup-management-type AzureIaasVM \
  --retain-until 2030-10-18

Friendly names are accepted in common single-VM cases, but native container and item names may be required when names are ambiguous or for advanced cross-subscription operations. Discover them with az backup container list and az backup item list rather than guessing.

radio_button_uncheckedshort_text9. Monitor configuration, snapshots, transfer, and jobs

At VM scope, inspect protection status, latest recovery point, policy, and last backup result. At vault scope, review protected items, storage consumption, alerts, and all backup jobs. The job detail separates Snapshot from Transfer data to vault, so a local restore point can exist while vault transfer is still running.

radio_button_uncheckedshort_text10. Choose the restore scope before launching a job

Instant Restore automatically uses the local snapshot when a recovery point has both snapshot and vault data. Vault restore is used when the snapshot is unavailable or ineligible. Restore duration depends on data size, tier, target IOPS and throughput, service queues, and the load on staging or target storage.

radio_button_uncheckedshort_text11. Understand cross-region, cross-subscription, and cross-zone restore

Always consult the current VM backup support matrix because combinations of policy subtype, disk type, encryption, managed identity, zone, region, subscription, private access, and recovery tier evolve independently.

radio_button_uncheckedshort_text12. Recover files and encrypted virtual machines safely

For item-level recovery, select a recovery point and generate the Azure Backup recovery script. Run it on a compatible machine to connect the recovery volumes, browse and copy required files, and then unmount the recovery point. The original backup schedule continues; file recovery does not replace the protected item.

Azure Backup supports protected VMs encrypted with Storage Service Encryption and supported Azure Disk Encryption configurations. Azure Disk Encryption uses BitLocker encryption keys (BEKs) and can use key-encryption keys (KEKs) stored in Azure Key Vault. Authorized restore procedures might need to recover keys or secrets before the VM can be rebuilt.

• File/folder recovery from an encrypted VM backup is not supported in the scenario described by the module; restore the VM or disks and copy the files afterward.
• Encrypted VM recovery commonly restores disks first and uses the supported script, template, PowerShell, or CLI procedure to recreate the VM.
• Replace-existing and cross-boundary options have additional encryption restrictions; verify the current matrix.
• Only authorized identities should restore key material. Azure and unauthorized users cannot read protected keys and secrets.

radio_button_uncheckedshort_text13. Lab: replace corrupted VM disks and track the restore

The source lab creates a general-purpose storage account as a staging location, stops the Windows VM, selects a recovery point, chooses Replace existing, and watches the restore job. In current managed-disk workflows the storage account can hold configuration metadata and temporary artifacts; restored managed disks live in the target resource group.

1. Create a uniquely named storage account in the lab resource group and region, then wait for successful validation and deployment.
2. Open the source VM and stop/deallocate it. Disk replacement fails the precheck while the VM is running.
3. From the VM Backup page or the protected item in Resiliency/vault, choose Restore VM and select an appropriate successful recovery point.
4. Choose Replace existing or Original Location Recovery and provide the required staging/target settings.
5. Review the destructive scope: current OS and selected data disks will be replaced, although Azure Backup takes a pre-replacement snapshot of current disks.
6. Trigger Restore, open Jobs, and inspect job details, real-time state, and every subtask until completion.
7. Boot the VM, validate the operating system and application, confirm networking and extensions, and record the achieved RTO and selected recovery point.

The source VM must still exist for disk replacement. If it was deleted, create a new VM or restore disks instead. A powered-off VM can be recreated or have disks restored, but disk replacement requires the source VM to be stopped and available.

radio_button_uncheckedshort_text14. Explain the knowledge-check answers

radio_button_uncheckedshort_text15. Compact review of every topic

radio_button_uncheckedshort_text16. Practice, cleanup, and current resources

• Build a decision table for accidental deletion, ransomware, zonal outage, and regional disaster, mapping each to Backup, availability, Site Recovery, or a combination.
• Create Standard and Enhanced policies, then compare RPO, local snapshot retention, vault retention, supported disks, resilience, and cost.
• Perform one file-level recovery and one isolated new-VM recovery before testing original-location disk replacement.
• Capture evidence for recovery point, job result, restore subtasks, application validation, achieved RTO, and cleanup.
• When finished, stop protection as intended, remove recovery points only with authorization, delete the vault in the correct order, and delete the lab resource group to avoid continued charges.

• Azure VM backup overview and consistency
• Back up a VM in the Azure portal
• Azure Backup Instant Restore
• Azure VM restore concepts and scenarios
• Restore a VM with Azure CLI
• Restore individual files from an Azure VM backup
• Back up and restore encrypted Azure VMs
• Azure VM backup FAQ and current limits
• Monitor Azure Backup
• Resiliency in Azure
• Azure CLI backup command reference
• Azure VM backup support matrix