If you’re coming from on-premises, you know that before you do any changes on a virtual machine (updates, upgrades, configuration changes, etc.), you do a snapshot of the disk just in case of a failure. This is something we’ve all ignored up to a point until it bit us badly and we’ve then just ran snapshots for every change.
The problem in the cloud is that you do not have the same easy way to do VM snapshots and restores in case of an issue. This changed in Azure when they introduced the OS Disk swap feature which allows administrators to run snapshots of a virtual machine, do their thing and if anything goes wrong they just restore the checkpoint.
As I mentioned above, if anything goes wrong with a VM that you’re maintaining then you have a few options available depending on the situation. Before OS Disk swap existed, your only solution to fixing a broken VM was to either restore it from Azure Backup, download the VHD and hope to fix it from a Hyper-V machine, and the worst case was to redeploy it. Now you have the option of just doing a snapshot of the VM, do your stuff and if something happens just swap in the good disk ?
Swapping the OS Disks is a simple operation that can be done via PowerShell or CLI (no portal support yet). You need either the latest AzureRM PowerShell Module installed on your computer or just use the Azure Cloud Shell – shell.azure.com
For this example, I will use my WorkStation VM in Azure located in the Workstation RG
Let’s start by setting the VM object in a variable:
$VM = Get-AzureRmVM -ResourceGroupName Workstation -Name Workstation-VMNow it’s time to stop the VM in order to have a consistent snapshot. – You can do skip this step if you don’t want to stop the VM.
Stop-AzureRmVM -Name $VM.Name -ResourceGroupName $VM.ResourceGroupNameWhile the VM is running or stopped you can now proceed to snapshot the current OS Disk:
$vmDiskName = $VM.StorageProfile.OsDisk.Name
$vmDiskObject = Get-AzureRmDisk -ResourceGroupName $VM.ResourceGroupName -DiskName $vmDiskName
$SnapshotConfig = New-AzureRmSnapshotConfig -SourceUri $vmDiskObject.Id -CreateOption Copy -Location $VM.Location
$takeSnapshot = New-AzureRmSnapshot -Snapshot $SnapshotConfig-SnapshotName "SNAP" -ResourceGroupName $VM.ResourceGroupName
Let’s assume that you utterly broke the VM, beyond repair so now you have to start the OS Disk Swap procedure. This part requires to stop the VM.
#stop the vm and create a new managed disk from the snapshot.
Stop-AzureRmVM -Name $VM.Name -ResourceGroupName $VM.ResourceGroupName
$genMSDiskFromSnapshot = Get-AzureRmSnapshot -SnapshotName SNAP -ResourceGroupName $VM.ResourceGroupName
$newDiskConfig = New-AzureRmDiskConfig -AccountType Premium_LRS -Location $vm.Location -CreateOption Copy -SourceResourceId $genMSDiskFromSnapshot.ID
$newMSDisk = New-AzureRmDisk -DiskName newOSDisk -Disk $newDiskConfig -ResourceGroupName $VM.ResourceGroupName
#Set the new OSDisk
Set-AzureRmVMOSDisk -VM $VM -ManagedDiskId $newMSDisk .Id -Name $newMSDisk.Name
Update-AzureRmVM -VM $vm -ResourceGroupName $vm.ResourceGroupName
The Update command will start up the VM and you will have reverted a disaster ?
After you RDP / SSH to the VM and validate that everything is working as before, you can just take the old disk image and play around with it in Hyper-V instance so you can see what happened or just delete it.
Signing off. Have a good one!
Platform guardrails prevent damage but often turn into friction machines. How to design guardrails that actually prevent bad patterns, layer detection and correction, and build platforms developers trust.
APIM isn't just a gateway. It's a governance layer that enforces consistency across AKS, Container Apps, and other platforms. When to use it and when to keep things simple.
If you're still deploying to Azure from GitHub Actions with static credentials in 2026, you have better options. Here's how to eliminate credentials from GitHub entirely using OIDC and workload identity, and why it matters.
