When backing up Linux VMs in Azure, you essentially have two main approaches: using the native Azure Backup service or manually creating snapshots through CLI commands. While both methods capture disk states at a point in time, their implementation and capabilities differ significantly.

# Azure CLI command for creating manual snapshots
az snapshot create \\
    --resource-group myResourceGroup \\
    --name mySnapshot \\
    --source /subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.Compute/disks/xxx

The Azure Backup vault is not just a simple storage account. It's a managed service layer providing:

• Multi-tiered storage architecture (similar to AWS Glacier but more flexible)
• Built-in retention policy management
• Application-consistent backups (unlike most manual snapshots)

Snapshots are region-bound resources. If you create a snapshot in East US, it remains in East US unless you explicitly copy it. Azure Backup offers cross-region restore capabilities out-of-the-box.

The "Unattached" state in the portal simply means the snapshot isn't currently mounted to any running VM. This is normal behavior - the snapshot exists as an independent resource until you either delete it or create a new disk from it.

# PowerShell example for creating VM from snapshot
$snapshotConfig = New-AzSnapshotConfig -SourceUri $snapshot.Id -Location $location -CreateOption Copy
$diskConfig = New-AzDiskConfig -Location $location -CreateOption Copy -SourceResourceId $snapshot.Id
$disk = New-AzDisk -Disk $diskConfig -ResourceGroupName $rgName -DiskName $diskName
$vm = Set-AzVMOSDisk -VM $vm -ManagedDiskId $disk.Id -Name $disk.Name

Use Azure Backup when you need:

• Enterprise-grade backup policies
• Cross-region protection
• Application-consistent backups

Use manual snapshots for:

• Quick, temporary protection during maintenance
• Scenario-specific disk captures
• When you need direct control over storage location

Azure Backup and manual snapshots serve different purposes in VM protection. When using az vm backup commands, Azure performs:

# Azure Backup workflow
1. Application-consistent snapshot (using VSS for Windows/pre-post scripts for Linux)
2. Initial full backup to Recovery Services vault
3. Subsequent incremental backups
4. Retention policy enforcement

Manual snapshots via CLI (az snapshot create) are crash-consistent only:

# Manual snapshot creation
az snapshot create \
  --resource-group myResourceGroup \
  --name mySnapshot \
  --source /subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.Compute/disks/xxx

The Recovery Services vault uses Azure's backend storage with these characteristics:

• Geo-redundant storage (GRS) by default
• Immutable storage architecture
• Compression and deduplication
• Unlike AWS Glacier, provides instant recovery capability

Both snapshots and backups are region-bound resources. For disaster recovery:

# Cross-region restore requires explicit configuration
az backup recoverypoint show-log-chain \
  --vault-name myVault \
  --resource-group myResourceGroup \
  --container-name myVM \
  --item-name myVM \
  --query [0].properties.region

The "Unattached" state indicates the snapshot exists independently of any VM. To check attachment status:

az disk list --query '[?sourceResourceId==/subscriptions/xxx/snapshots/mySnapshot]' \
  --output table

For production Linux VMs, consider this hybrid approach:

# Daily Azure Backup for point-in-time recovery
az backup protection enable-for-vm \
  --resource-group myResourceGroup \
  --vault-name myVault \
  --vm $(az vm show -g myResourceGroup -n myVM --query id -o tsv)

# Manual snapshots before critical updates
az snapshot create --name "pre-update-$(date +%Y%m%d)" \
  --resource-group myResourceGroup \
  --source /subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.Compute/disks/xxx