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

3 + 4 = ?

Snapshot VMs in Azure

Unlike traditional (on-premise) virtualisation infrastructures where it is a relatively simple process to ‘snapshot’ a virtual machine at any one point in time (thereby allowing you to restore that virtual machine back to that specific point in time), Microsoft Azure does not natively offer this functionality.

Probably the easiest way of backing up an Azure VM is to use “Server Backup” from within the Windows OS (backing up to an attached disk via blob storage), but as we all know this is nowhere near as convenient as being able to simply restore a server image back to a specific point in time.

Fortunately through the use of a series of PowerShell commands, it is possible to provide this type of backup/restore functionality – and in this blog I’ll show you how…

Install Azure PowerShell

First things first, if you haven’t already then you need to install the Azure PowerShell extensions. The easiest way to do this is to run the Microsoft Web Platform Installer following the prompts to complete installation.

Connect To Your Azure Subscription

Next we need to connect (through Azzure PowerShell) to our Azure subscription. There are two methods of connecting to your subscription: –

  • Azure AD method
  • Azure Certificate method

Although self explanatory, the Azure Certificate method is more convoluted so for the purpose of this exercise we’ll use the Azure AD method. After opening the Azure PowerShell type the following command:

Add-Azure Account

In the pop-up window that appears type the email address and password associated with the Azure account that the VM’s (that you wish to backup/restore) are running under.

Azure will authenticate, save the credential information, and subsequently close the window.

Your Azure PowerShell session will stay authenticated for 12 hours (when using the Azure AD method of authentication), after which time you will be forced to re-authenticate. Remember you can have more than one Azure subscription per account, and in fact you can add as many accounts to your Azure PowerShell session as you like. To get a list of Azure accounts and/or subscriptions type one of the following commands:

Get-AzureAccount

Backup VM

To backup a VM in Azure we need to step through the following activities: –

  • Create a cloud storage container for storing backups
  • Select a virtual machine to backup
  • Identify each virtual hard disk for the virtual machine
  • Backup those virtual hard disks to the cloud storage container

Create a Cloud Storage Container

For the purpose of this exercise I have assumed that we want to keep our VM backups in Azure. There would be nothing stopping us from storing the backups locally on-premise. One benefit of this would be that you would not be paying for the storage costs in Azure, and this may become a consideration if you intend to make several backups, at different points in time, of the same machine. But for the purpose of this exercise we’re going to store our backups in Azure in the same subscription.

Prior to performing any backups we need to make sure that we have a cloud storage container to store the backups, and the first thing to do in order to create the cloud storage container is to ascertain the name of our Azure Storage Account. The easiest way of determining this is from the MediaLink property of an existing VM’s OS disk. In Azure PowerShell type the following commands: –

GetAzureVM

This will give you a list of the Azure VM’s currently assigned to the Azure Subscrption you are connected to.

$vmOSDisk = Get-AzureVM -ServiceName me-agresso-dc01 | getAzureOSDisk

This will assign the operating system disk object to the variable $vmOSDisk

Note

me-agresso-dc01 is the name of the VM that I have selected from my list of VM’s – you will need to substitute this with the name of your own VM.

$StorageAccountName = $vmOSDisk.MediaLink.Host.Split('.')[0]

Now if you type the following command you will see your perfectly parsed Azure Storage Account Name:

$StorageAccountName

Before we actually create our storage container, let’s take a look at what storage containers currently exist by typing the following command:

Get-AzureStorageContainer

To create a new storage container to hold our backups type the following command: –

New-AzureStorageContainer -Name backups -Permission off

That last command will have created a storage container named backups. Just to prove it has successfully been created, let’s take another look at what storage containers currently exist in our subscription:

Get-AzureStorageContainer

Select a VM to Backup

Next up we need to select the VM that we wish to backup – we can remind ourselves of the list of VM’s assigned to our current Azure Subscription with the following command: –

Get-AzureVM

Now let’s choose one of the VM’s and assign it to the variable $vm for future use within PowerShell:

$vm = Get-AzureVM –ServiceName me-agresso-dc01 –Name me-agresso-dc01

Note

me-agresso-dc01 is the name of the VM that I have selected from my list of VM’s – you will need to substitute this with the name of your own VM.

It is best practice to ensure the virtual machine is stopped prior to backup. Type the following command to report all of the relevant properties for your selected VM:

$vm

Note the Power State of the VM. If it is not set to “Stopped” then you will need to stop the VM using the following command:

$vm | StopAzureVM -StayProvisioned

Identify Virtual Hard Disks

Next we need to identify all of the VHD’s (Virtual Hard Disks) allocated to the VM. VM’s in Azure are provisioned with two general types of virtual hard disk:

  • Operating System Disks
  • Data Disks

Every VM will have an Operating System Disk from which it boots and runs the OS from. In addition each VM may have one or more additional Data Disks (although it must be noted that some VMs may not have a Data Disk at all).

In order to perform a complete Virtual Machine backup it is necessary to locate ALL of the VHDs that are currently being used by our VM.

Using the variable $vmOSDisk let’s store the location of our OS disk for the selected VM that we wish to backup:

$vmOSDisk = $vm | Get-AzureOSDisk

Using another variable $vmDataDisks let’s store the location of our Data Disks: –

$vmDataDisks = $vm | Get-AzureDataDisk

Note

Owing to the fact a VM may have more than one Data Disk, the value type returned (and stored in the variable) is actually a Collection – when working with a collection, we will need to use a ForEach loop

Perform Backup

First off we’ll create a backup of the Operating System Disk, and then we’ll make a backup of any Data Disks.

We need to identify the blob and container names for the VHD’s we want to backup, and assign them to local variables. To do this type the following commands:

$vmOSBlobName = $vmOSDisk.MediaLink.Segments[-1]
$vmOSContainerName = $vmOSDisk.MediaLink.Segments[-1].Split('/')[0]

Now we have the blob and container names for the Operating System Disk, let’s go ahead and perform the backup:

Start-AzureStorageBlobCopy -SrcContainer $vmOSContainerName -SrcBlob $vmOSBlobName -DestContainer backups

AzureStorageBlobCopy is an asynchronous process which runs in the background on the Azure platform. To determine when the process is completed you can use the command Get-AzureStorageBlobCopyState like this:

Get-AzureStorageBlobCopyState -Container backups -Blob $vmOSBlobName -WaitForComplete

Note

backups is the name of the storage container I created earlier, obviously you will need to substitute this with the name of the storage container you created.

Now we’ve created a backup of the Operating System Disk, we need to create the backups for all (if any) existing Data Disks attached to the VM. However because this time we are working with a Collection we will need to run the backup command from within a ForEach loop:

ForEach ($vmDataDisk in $vmDataDisks) {
$vmDataBlobName = $vmDataDisk.MediaLink.Segments[-1]
$vmDataContainerName = $vmDataDisk.MediaLink.Segments[-2].Split('/')[0]
Start-AzureStorageBlobCopy -SrcContainer $vmDataContainerName -SrcBlob $vmDataBlobName -DestContainer backups -Force
Get-AzureStorageBlobCopyState -Container backups -Blob $vmDataBlobName -WaitForComplete
}

Note

backups is the name of the storage container I created earlier, obviously you will need to substitute this with the name of the storage container you created.

From a backup perspective – that’s it! You’ve successfully backed up the Operating System Disk and any attached Data Disks to the Storage Container that you created earlier.

Restore VM

To restore a VM in Azure we need to step through the following activities:

  • Select the VM to restore
  • Identify all VHD’s to be restored
  • De-provision the VM
  • Restore the Azure VM OS disk
  • Restore the Azure VM Data disk(s)
  • Re-provision the VM

Select the VM to Restore

First off we need to select the VM to restore (I am assuming you have opened up a session in Azure PowerShell and connected to your relevant subscription – if not then refer back to the top of this blog entry).

Now type the following commands:

Get-AzureVM

This will give you a list of all the VM’s for the subscription that you are currently connected to. Now let’s select the VM we wish to restore :

$vm = Get-AzureVM –ServiceName me-agresso-dc01 –Name me-agresso-dc01

Note

me-agresso-dc01 is the name of the VM that I have selected to restore from my list of VMs – you will need to substitute this with the name of your own VM (note that we’ve used the variable $vm to hold the details of the selected VM).

Now that we’ve selected our VM, we need to make sure that it’s powered off and that it’s configuration is kept in a provisioned state – to do this type the following command:

$vm | Stop-AzureVM –StayProvisioned

Identify Virtual Hard Disks to Restore

Next we need to identify all of the VHDs (Virtual Hard Disks) allocated to the VM. VMs in Azure are provisioned with two general types of virtual hard disk:

  • Operating System Disk
  • Data Disks

Every VM will have an Operating System Disk from which it boots and runs the OS from. In addition each VM may have one or more additional Data Disks (although it must be noted that some VMs may not have a Data Disk at all).

In order to perform a complete Virtual Machine restore it is necessary to locate ALL of the VHDs that are currently being used by our VM.

To store the location of the OS Disk and Data Disks using local variables type the following command:

$vmOSDisk = $vm | Get-AzureOSDisk
$vmDataDisks = $vm | Get-AzureDataDisk

Note

Owing to the fact that there may be more than one Data disk attached to the VM, the command Get-AzureDataDisk actually returns a Collection, which we will need to iterate through using a ForEach loop (assuming there are disks in the collection of course).

The two properties that we specifically require are the DiskName and MediaLink values, these values provide the specific information we require when performing a restore.

De-Provision VM

When a VM is provisioned in Azure the platform places a lease on each VHD to ensure the disk is not inadvertently deleted. Therefore it’s necessary to completely remove the VM in order to delete and restore the VHD. However, we need to keep the VM configuration in order to recreate it once the VHD has been restored.

The easiest way to achieve this is to create a local folder on your machine and copy the VM config from Azure, thereby allowing us to delete the VM from Azure whilst maintaining the original VM configuration. In order to achieve this, type the following commands:

$exportFolder = “C:/ExportVMs
if (!(Test-Path –Path $exportFolder)) {
New-Item –Path $exportFolder –ItemType Directory
}
$exportPath = $exportFolder + “” + $vm.Name + “.xml”
$vm | Export-AzureVM –Path $exportPath

Note

I chose the folder C:/ExportVMs but you will need to replace this with the folder of your choice.

If you look in the local folder you will now see an XML file containing the configuration of your selected Azure VM.

Now the Azure VM configuration has successfully been exported, it is now time to remove it from Azure, allowing the system to release the lock held on any VHDs. To do this type the following command:

Remove-AzureVM –ServiceName $vm.ServiceName –Name $vm.Name

Restore the VM OS Disk

In order to restore the selected VM’s OS disk from the storage container, then we must first define a few local variables:

$vmOSDiskName = $vmOSDisk.DiskName
$vmOSDiskuris = $vmOSDisk.MediaLink
$StorageAccountName = $vmOSDiskuris.Host.Split('.')[0]
$vmOSBlobName = $vmOSDiskuris.Segments[-1]
$vmOSOrigContainerName = $vmOSDiskuris.Segments[-2].Split('/')[0]
$backupContainerName = “backups

Note

backups is the name of the storage container I created earlier, obviously you will need to substitute this with the name of the storage container you created.

After removing an Azure VM there is sometimes a short period of time where the VHDs are still listed as being attached to a VM (i.e. the lock is still in place). We just need to wait until the virtual hard disk is successfully reporting that it is no longer attached to a VM. The easiest way to do this is to use the Get-AzureDisk command from within a While loop. To do thi, type the following command:

While ( (Get-AzureDisk –DiskName $vmOSDiskName).AttachedTo ) { Start-Sleep 5 }

Once you have run this command to ensure the OS Disk is detached, you will need to remove the current disk in preparation for restoring the disk from backup – type the following command:

Remove-AzureDisk –DiskName $vmOSDiskName –DeleteVHD

You’re now ready to restore the OS Disk from backup – type the following command:

Start-AzureStorageBlobCopy –SrcContainer $backupContainerName –srcBlob $vmOSBlobName –DestContainer $vmOSOrigContainerName –Force

Remember that a Storage Blob Copy is an asynchronous operation, so it is prudent to check the status of the copy process and to wait until it is complete. This can be achieved using the following command:

Get-AzureStorageBlobCopyState –Container $vmOSOrigContainerName –Blob $vmOSBlobName –WaitForComplete

Once the copy has completed you can add the disk back into your subscription for the restored VM OS Disk – type the following command:

Add-AzureDisk –DiskName $vmOSDiskName –MediaLocation $vmOSDiskuris.AbsoluteUri –OS Windows

Restore the VM Data Disk(s)

Assuming your VM has one or more Data Disks attached to it (and you wish to restore them too) then we use a similar process for restoring these disks to what we used for restoring the OS Disk. However since the Data Disks are returned to us as a Collection then we need to run the relevant commands inside a ForEach loop to iterate through each disk in turn.

Note

It is possible that your VM does NOT have any Data Disks attached, or that you do not wish to restore your Data Disks from a previous version. In either of these cases then you can ignore this section and move straight to “Re-provision Virtual Machine”.

Type the following commands:

ForEach ( $vmDataDisk in $vmDataDisks ) {
$vmDataDiskName = $vmDataDisk.DiskName
$vmDataDiskuris = $vmDataDisk.MediaLink
$vmDataBlobName = $vmDataDiskuris.Segments[-1]
$vmDataOrigContainerName = $vmDataDiskuris.Segments[-2].Split('/')[0]
While ( (Get-AzureDisk -DiskName $vmDataDiskName).AttachedTo ) { Start-Sleep 5 }
Remove-AzureDisk -DiskName $vmDataDiskName –DeleteVHD
Start-AzureStorageBlobCopy -SrcContainer $backupContainerName -SrcBlob $vmDataBlobName -DestContainer $vmDataOrigContainerName –Force
Get-AzureStorageBlobCopyState -Container $vmDataOrigContainerName -Blob $vmDataBlobName –WaitForComplete
Add-AzureDisk -DiskName $vmDataDiskName -MediaLocation $vmDataDiskuris.AbsoluteUri
}

You will now have successfully iterated through the Data Disk Collection and restored each of the Data Disks that were attached to your VM.

Re-Provision the VM

So here we are – at the final stage. Once we’ve completed the restore of all the VHDs (OS Disks and Data Disks) then we need to re-provision the VM using the VM config that we saved locally earlier, using command Import-AzureV.

Type the following command:

Import-AzureVM –Path $exportPath | New-AzureVM –ServiceName $vm.ServiceName

When the import process has completed the VM will have been restored and will automatically be started.

Warning

If your VM is assigned to a custom Virtual Network then you MUST specify that network as part of the Import-AzureVM command, otherwise you will get an error message. If you do have a custom virtual network that the VM is assigned to, then replace the above command with this one:

Import-AzureVM –Path $exportPath | New-AzureVM –ServiceName $vm.ServiceName –VnetName ca_me_test_agresso_01

Note

ca_me_test_agresso_01 is the name of our custom virtual network that the Azure VM is assigned to.

And that’s it – using this process you can backup and restore (snapshot a point in time, and restore back to that point in time) any Azure VM. Although you could follow this blog each and every time, I would highly recommend you use the commands within this blog to build your own automated PowerShell scripts. Feel free to drop me a line if you have any questions, or if you wish to share any of those automated PowerShell scripts mark.briggs@coreazure.com