Disk Snapshots and Custom VM Images

A disk snapshot is a read-only, point-in-time copy of a virtual hard disk (VHD) used by an Azure VM. Snapshots exist to provide fast, low-cost backup and restore capabilities without needing to copy the entire disk. They are essential for protecting against data corruption, accidental deletion, or configuration errors before applying updates. Snapshots are also used to create new disks from a specific state, such as before a risky change.

Custom VM images, on the other hand, are generalized VM configurations that include the OS, applications, and settings, stripped of machine-specific identifiers (like SID, hostname). Images enable rapid, consistent deployment of multiple VMs with identical configurations. They are fundamental for scaling out workloads, creating development/test environments, and implementing infrastructure-as-code.

Azure snapshots use Copy-on-Write (CoW) technology for managed disks. When you create a snapshot of a managed disk, Azure does not immediately copy all data blocks. Instead, it creates a differential snapshot: it records a mapping of which blocks existed at snapshot time. The snapshot initially shares the same underlying storage blocks as the source disk. When a write occurs to a block on the source disk after the snapshot, the original block is copied to the snapshot storage before the write proceeds. This ensures the snapshot always reflects the state at the time of creation, without blocking writes.

For unmanaged disks (stored in a storage account as page blobs), snapshots are full copies by default. Azure creates a new page blob and copies all data. This is slower and more expensive than managed disk snapshots. The exam frequently tests this distinction: managed disk snapshots are incremental; unmanaged disk snapshots are full.

To create a snapshot of a managed disk using Azure CLI:

az snapshot create \
  --resource-group myResourceGroup \
  --name mySnapshot \
  --source myDisk

For a specific source disk ID:

diskId=$(az disk show --resource-group myResourceGroup --name myDisk --query id --output tsv)
az snapshot create \
  --resource-group myResourceGroup \
  --name mySnapshot \
  --source $diskId

To create a disk from a snapshot:

az disk create \
  --resource-group myResourceGroup \
  --name myNewDisk \
  --source mySnapshot

To attach the disk to a VM:

az vm disk attach \
  --resource-group myResourceGroup \
  --vm-name myVM \
  --name myNewDisk

Using PowerShell:

$disk = Get-AzDisk -ResourceGroupName myResourceGroup -DiskName myDisk
$snapshot = New-AzSnapshotConfig -Location $disk.Location -SourceUri $disk.Id -CreateOption Copy
New-AzSnapshot -ResourceGroupName myResourceGroup -SnapshotName mySnapshot -Snapshot $snapshot

A custom VM image is created from a generalized VM. Generalization removes machine-specific information using Sysprep (for Windows) or waagent -deprovision (for Linux). The process: 1. Run Sysprep with /generalize /shutdown on Windows. This resets the Security Account Manager (SAM), clears event logs, and prepares the OS for imaging. 2. Run sudo waagent -deprovision+user on Linux. This deletes SSH host keys, resets configuration, and prepares the VM. 3. After generalization, the VM is stopped and deallocated. 4. Capture the image using the Azure portal, CLI, or PowerShell.

Azure CLI command to capture an image:

az vm deallocate --resource-group myResourceGroup --name myVM
az vm generalize --resource-group myResourceGroup --name myVM
az image create \
  --resource-group myResourceGroup \
  --name myImage \
  --source myVM

The image is stored as a managed resource in the same region. You can then create VMs from it:

az vm create \
  --resource-group myResourceGroup \
  --name myNewVM \
  --image myImage \
  --admin-username azureuser \
  --generate-ssh-keys

In a typical enterprise scenario, snapshots are used for pre-maintenance backups. For example, before applying a critical security patch to a production SQL Server VM, the DBA takes a snapshot of the OS and data disks. If the patch causes issues, the DBA can quickly create new disks from the snapshots and attach them to a new VM, restoring the database to the pre-patch state. This process takes minutes, whereas a full backup restore from Azure Backup could take hours. However, snapshots are not a replacement for Azure Backup because they lack long-term retention and cross-region redundancy. In practice, snapshots are often used in conjunction with Azure Backup for tiered protection: snapshots for quick recovery, backup for archival.

Another scenario involves custom images for scaling out a web application. The DevOps team builds a golden image with the OS, IIS, and application code. They generalize the VM and capture an image. Using Azure DevOps, they deploy a VM Scale Set referencing this image. When demand spikes, the scale set automatically creates new VMs from the image, ensuring identical configuration. The team updates the image monthly by patching the source VM, re-generalizing, and updating the image. They use Azure Policy to enforce that all web VMs must be from the approved image. Common misconfigurations include forgetting to deallocate before capture, which results in a failed capture, or not running sysprep, which leads to duplicate SIDs and domain join issues.

A third scenario involves disaster recovery. A company replicates VMs to a secondary region using Azure Site Recovery. For application-consistent recovery points, they use snapshots with VSS on Windows. The snapshot ensures that the database files are in a consistent state. Without VSS, the snapshot would be crash-consistent, which might require database recovery on failover. The exam tests the difference between crash-consistent and app-consistent snapshots.