Snapshot VMs in Azure Resource Manager

One of our most-popular blog posts (drawing almost a quarter of all visitors to our site) has been Mark Briggs’ excellent Snapshot VMs in Azure guide from August 2014. Although much of the content of this article is still relevant for virtual machines created using the classic Azure portal, there have been a number of major changes to the Microsoft Azure platform in the interim, including the introduction of the Azure Resource Manager (ARM) deployment model, along with significant changes to the Azure PowerShell modules which may result in unexpected behaviour and warnings about deprecated features.

I thought it would be useful to provide an updated guide for creating snapshots from virtual machines which have been created in the new Azure portal (https://portal.azure.com) using the Azure Resource Manager deployment model.


Warning

The following guide has been provided purely for informational purposes and should be thoroughly tested on non-critical systems. CoreAzure cannot be held responsible for any consequences arising from the use of this information.

Step 1: Install Azure PowerShell

If you haven’t already installed the latest Azure modules for PowerShell, you can do so using the following steps:

  1. Open an administrative Command Prompt. The easiest way is to right-click on the Start button and select Command Prompt (Admin).
  2. Enter the command powershell and press Return to start a Windows PowerShell session.
  3. Enter the command Install-Module AzureRM and press Return.
  4. If you are prompted to install the NuGet provider, type and press Return to confirm.
  5. If you receive a warning about an untrusted repository, type and press Return to add PSGallery to the list of trusted repositories.

Step 2: Validate current VM configuration

We now need to take a look at the configuration of the virtual machine we wish to snapshot as the script we will be using to perform the operation needs to know details such as the resource group which contains the VM, its network configuration, storage account and disk configuration as well as the Azure region which hosts the VM.

The easiest way to do this is to login to the new Azure portal (https://portal.azure.com) and open the resource group containing the VM you wish to snapshot. This will provide a list of all resources associated with the virtual machine.

For this demonstration, I have created a test resource group named snapshotrg in the UK South region containing the resources shown in the screenshot below:

Resource Group Properties

Resource Group Properties

As you can see, the resource group contains a virtual machine named snapshotvm connected to a virtual network called snapshotvn via a network interface named snapshotvm156. This network interface has a public IP address assigned named snapshotpip, along with a Network Security Group called snapshotnsg which contains a single rule to allow incoming RDP connections.

The virtual machine is connected to a storage account named snapshotsa which contains a single container named vhds. Inside this container is the virtual machine’s OS disk named snapshotvm20170221112834.vhd.

We can ignore the other storage account (snapshotrgdiag735) listed in the resource group as this has been automatically generated by Azure for boot logging purposes and does not need to be included in any snapshot operations.

Virtual Machine Properties

Virtual Machine Properties

If we look at the properties of the virtual machine itself, we can see that it is a Windows server with a VM size of Standard F1s. The public IP address it has been assigned is 51.140.29.163 which has been given a DNS name of snapshotvm.uksouth.cloudapp.azure.com. We can also make a note of the Subscription Name.

The final piece of information we need to gather is the storage account key used to communicate with the storage account (as our script will be creating snapshots in the same container as the original OS disk). To do this, simply open the properties of the storage account (in my case, snapshotsa) and select the Access keys option. You should now be presented with two access keys, either of which can be copied into our script in Step 3.

Step 3: Populate local variables

We can now use the information gathered in Step 3 to start creating our snapshot script. Launch Windows PowerShell ISE and enter the following into the script pane (replacing the text in angled brackets with the details relevant to your environment). To see the code I used for the snapshotvm virtual machine, click on the Example tab:

Code
$resourceGroupName = "<Insert Resource Group Name Here>"
$location = "<Insert Azure Region Here>"
$vmName = "<Insert VM Name Here>"
$vmSize = "<Insert VM Size Here>" 
$vnetName = "<Insert vNet Name Here>"
$nicName = "<Insert NIC Name Here>" 
$dnsName = "<Insert DNS Name Here>" 
$diskName = "<Insert Disk Name Here (omitting the .vhd extension)>" 
$storageAccount = "<Insert Storage Account Name Here>" 
$storageAccountKey = "<Insert Storage Account Key Here>" 
$subscriptionName = "<Insert Subscription Name Here>" 
$publicIpName = "<Insert Public IP Address Name Here>"
Example
$resourceGroupName = "snapshotrg" 
$location = "UK South" 
$vmName = "snapshotvm" 
$vmSize = "Standard_F1s" 
$vnetName = "snapshotvn" 
$nicName = "snapshotvm156" 
$dnsName = "snapshotvm" 
$diskName = "snapshotvm20170221112834" 
$storageAccount = "snapshotsa" 
$storageAccountKey = "<OBFUSCATED>" 
$subscriptionName = "Pay-As-You-Go" 
$publicIpName = "snapshotpip"

We can concatenate some of the information provided above to give us the full name of the disk blob, target backup disk blob and full path to the VHD which will be stored in the following variables:

$diskBlob = "$diskName.vhd"
$backupDiskBlob = "$diskName-backup.vhd"
$vhdUri = "https://$storageAccount.blob.core.windows.net/vhds/$diskBlob"
$subnetIndex = 0

Step 4: Login to your Azure subscription

We now need to configure our script to login to Microsoft Azure and connect to the right subscription. For maximum security, Microsoft recommend using a service principal and certificate to login to Azure. This is especially true when you have created batch scripts or apps which need to run without prompting for additional credentials (and which you wouldn’t necessarily want to run under your own credentials). However, configuring this method of authentication falls outside the scope of this tutorial, so we will be using Azure AD credentials for simplicity.

To login to Azure and connect to the required subscription, we can use the Login-AzureRmAccount and Set-AzureRMContext commands in conjunction with the $subscriptionName variable we defined earlier:

Add-AzureRmAccount 
Set-AzureRMContext -SubscriptionName $subscriptionName

When these commands are run, a window should automatically appear prompting you to login to Azure. Assuming the correct credentials are provided, the window will disappear and take you back to the active PowerShell session.

Step 5: Create backup disk

To create a snapshot of the disk, we first need to power off the virtual machine using the following command:

Stop-AzureRmVM -ResourceGroupName $resourceGroupName -Name $vmName -Force -Verbose

We can then check to see if a backup has already been created using the following commands:

$ctx = New-AzureStorageContext -StorageAccountName $storageAccount -StorageAccountKey $storageAccountKey
$blobCount = Get-AzureStorageBlob -Container vhds -Context $ctx | where { $_.Name -eq $backupDiskBlob } | Measure | % { $_.Count }

If no backup disk is currently found in the container, we can proceed with creating a copy. Although the copy operation should be relatively quick (as the target file is located in the same storage container), I’ve included a while loop to report the copy status every 10 seconds. This might prove useful if you want the snapshot to be copied to a different region or on a local file server:

if ($blobCount -eq 0)
{
$copy = Start-AzureStorageBlobCopy -SrcBlob $diskBlob -SrcContainer "vhds" -DestBlob $backupDiskBlob -DestContainer "vhds" -Context $ctx -Verbose
$status = $copy | Get-AzureStorageBlobCopyState
$status
While($status.Status -eq "Pending"){
$status = $copy | Get-AzureStorageBlobCopyState
Start-Sleep 10
$status
}
}

We can now check the vhd storage container in the portal to confirm that the copy has been created:

Original VHD and Backup

Original VHD and Backup

Step 6: Delete original resources

With our snapshot created, we can test the restore process by deleting some of the original resources. The following script should delete the original virtual machine, along with its disk, network interface and public IP address:

Remove-AzureRmVM -ResourceGroupName $resourceGroupName -Name $vmName -Force -Verbose
Remove-AzureStorageBlob -Blob $diskBlob -Container "vhds" -Context $ctx -Verbose
Remove-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $resourceGroupName -Force -Verbose
Remove-AzureRmPublicIpAddress -Name $publicIpName -ResourceGroupName $resourceGroupName -Force -Verbose

To validate that the resources have been deleted, log back into the Azure portal and open the properties of your resource group. The only resources remaining should be the Network Security Group, Virtual Network and storage accounts:

Resource Group After Deletion

Resource Group After Deletion

Step 7: Recreate original disk

We still have the name of the original disk recorded in our $diskBlob variable, so we can easily recreate this disk by creating a copy of our backup disk using this name. Again, I’ve included a 10-second status check loop in case the copy operation takes longer than expected:

$copy = Start-AzureStorageBlobCopy -SrcBlob $backupDiskBlob -SrcContainer "vhds" -DestBlob $diskBlob -DestContainer "vhds" -Context $ctx -Verbose
$status = $copy | Get-AzureStorageBlobCopyState 
$status 
While($status.Status -eq "Pending"){
  $status = $copy | Get-AzureStorageBlobCopyState 
  Start-Sleep 10
  $status
}

Step 8: Recreate resources

With the original disk now back in place, we can proceed with recreating the virtual machine and its associated network resources:

$vnet = Get-AzureRmVirtualNetwork -Name $vnetName -ResourceGroupName $resourceGroupName
$pip = New-AzureRmPublicIpAddress -Name $publicIpName -ResourceGroupName $resourceGroupName -DomainNameLabel $dnsName -Location $location -AllocationMethod Dynamic -Verbose
$nic = New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $resourceGroupName -Location $location -SubnetId $vnet.Subnets[$subnetIndex].Id -PublicIpAddressId $pip.Id -Verbose
$vm = New-AzureRmVMConfig -VMName $vmName -VMSize $vmSize
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id
$vm = Set-AzureRmVMOSDisk -VM $vm -Name $diskName -VhdUri $vhdUri -CreateOption attach -Windows

Step 9: Examine the result

We can now repeat the checks we carried out in Step 2 to see how our environment has changed. If we open the properties of the snapshotrg resource group, we can see that the snapshotvm machine and the public IP address are now present and correct. However, it now has a new network interface named snapshotvm156:

Resource Group After Restore

Resource Group After Restore

If we look at the properties of the public IP address snapshotpip, we can see that a new public IP address of 51.140.27.233 has been assigned. However, it has retained the correct DNS name (so anything which communicates with the server by DNS will still operate correctly). If we didn’t want the public IP address of the server to change, we could have left the old public IP address undeleted (and reassigned it after the new machine was created):

Public IP Address After Restore

Public IP Address After Restore

If we look at the properties of the virtual machine itself, we can see that the new virtual machine has been created with the correct VM size, location and subscription name:

Virtual Machine Properties After Restore

Virtual Machine Properties After Restore

Finally, looking at the disk configuration of the new virtual machine confirms that it is using the original disk name (although the backup file is still available in the vhds container should you need to restore the snapshot again in future):

Disk Configuration After Restore

Disk Configuration After Restore

I hope this guide proved useful. You can download the full PowerShell script using the button below:

Please do not hesitate to contact me using the form below if you have any queries.

Send us mail

1 + 0 = ?