Azure Disk Snapshots: How They Work and When to Use Them

How snapshots work

A snapshot captures the exact state of a managed disk at the moment you take it. The first snapshot of a disk is a full copy — stored in Azure Blob storage in the same region as the disk. All subsequent snapshots are incremental: only the disk blocks that changed since the last snapshot are stored.

Despite being incremental in storage, you can restore from any single snapshot directly. Azure reconstructs the full disk state from the incremental chain without you needing to manage that process. Deleting an intermediate snapshot does not break later snapshots — Azure merges the delta into the next one automatically.

Snapshots are stored redundantly using locally redundant storage (LRS) by default, meaning three copies within a single data center. For disaster recovery purposes where you need the snapshot to survive a regional outage, use zone-redundant storage (ZRS) or copy the snapshot to another region.

Creating snapshots with the Azure CLI

You need the source disk resource ID. For a running VM’s OS disk, get it from the VM properties:

# Get the OS disk ID for a VM
DISK_ID=$(az vm show \
  --resource-group my-rg \
  --name my-vm \
  --query storageProfile.osDisk.managedDisk.id \
  --output tsv)

echo $DISK_ID

# Take a snapshot (VM can remain running)
az snapshot create \
  --resource-group my-rg \
  --name my-vm-snapshot-$(date +%Y%m%d) \
  --source $DISK_ID \
  --incremental true

The —incremental true flag is important — it enables incremental snapshots, which are cheaper for subsequent snapshots. Use full snapshots only when you want a fully independent copy with no dependency on previous snapshots (for example, before cross-region migration).

You can take a snapshot of a running VM without stopping it first. However, the snapshot will capture the disk state at a specific moment — if the application was in the middle of writing data, the snapshot may be crash-consistent (recoverable, like after a power cut) rather than application-consistent (cleanly quiesced). For database VMs, stop writes or use Azure Backup’s VSS-based consistent snapshots.

Restoring a VM from a snapshot

You do not restore a snapshot directly onto an existing disk. Instead, you create a new managed disk from the snapshot and either replace the VM’s disk or create a new VM from it.

Scenario: restore a VM after a bad deployment

# Step 1: Deallocate the VM
az vm deallocate --resource-group my-rg --name my-vm

# Step 2: Create a new managed disk from the snapshot
az disk create \
  --resource-group my-rg \
  --name restored-os-disk \
  --source /subscriptions/.../snapshots/my-vm-snapshot-20260319 \
  --sku Premium_LRS

# Step 3: Swap the OS disk on the VM
az vm update \
  --resource-group my-rg \
  --name my-vm \
  --os-disk restored-os-disk

# Step 4: Start the VM
az vm start --resource-group my-rg --name my-vm

This approach is non-destructive — the original (broken) disk still exists until you explicitly delete it. You can swap back to it if the snapshot restoration does not resolve the issue.

Practical snapshot use cases

Pre-change safety point

Before a major OS update, database migration, or application deployment, take a snapshot of the relevant disk. If the change causes problems, you can roll back by creating a new disk from the snapshot and swapping it in. This is particularly useful for VMs that do not have a clean deployment pipeline — legacy servers where rollback would otherwise mean manual reinstallation.

Cloning an environment

Snapshots are useful for creating a copy of a production environment for testing a data migration or debugging a production-specific issue. Take a snapshot of the production disk, create a new disk from it, attach it to a new VM in a separate resource group or subscription, and test on a real copy of the data without affecting production.

Cross-region disk migration

You cannot move a managed disk directly between regions. The workaround is: take a snapshot, copy the snapshot to the target region, then create a new disk from the copy.

# Copy a snapshot to another region
az snapshot copy \
  --resource-group my-rg \
  --source /subscriptions/.../snapshots/my-snapshot \
  --destination-resource-group my-rg-westeurope \
  --destination-name my-snapshot-westeurope \
  --destination-region westeurope

Snapshots versus Azure Backup

Snapshots and Azure Backup both protect VM data, but at different levels of automation and control.

For VMs that process business data and need regular automated backups, Azure Backup is the right tool. Use disk snapshots as a complement to Azure Backup for ad hoc situations, not as a replacement for a scheduled backup policy.