In our Cloud-first world, many organizations are starting to explore and use Microsoft Azure as an extension (or maybe even a replacement) of their data centers.

Either way, if you’re on this Cloud adventure, you probably have at least a few Virtual Machines running in Azure. If you do, then you need to extend your Business Continuity and Disaster Recovery (BCDR) strategy into the cloud as well.

In Azure, you can configure Virtual Machine backups very easily. In fact, in December 2016 Microsoft announced the new ability to backup an Azure VM directly from the VM blade.

VM Blade Backup

For anyone that’s new to Azure Backup, here’s a good starting point: Protect Azure VMs with a Recovery Services Vault.

So now that we have our Azure VMs backed up, let’s explore the 3 options we have for restoring our Virtual Machines.

 

Restore Option 1: Create A Virtual Machine

The first option we have for restoring an Azure VM is with the “Create Virtual Machine” restore type.

Note: This option is equivalent to the Quick Create option.

Azure Backup – Restore – Create a Virtual Machine

This works for a quick-and-dirty restore to get a basic VM restored and up and running. However, if your Virtual Machine has some special configurations like the following, we need to do more:

  • VMs under load balancer (internal and external)
  • VMs with multiple reserved IPs
  • VMs with multiple NICs

If any of your VMs have these configurations, you’re going to need to use the next option for restoring (Disk Restore).

 

Restore Option 2: Restore Disks

So if your Virtual Machine has a special configuration (mostly networking related), you’re going to have to break out the PowerShell.

Instead of using the “Create a Virtual Machine” restore type, we need to use the “Restore Disks” option.

Azure Backup – Restore – Restore Disks

This will make a copy of the VHDs into the Storage Account you specify. From this point, you now have 2 options; either attach the restored disks to an existing Virtual Machine or create a new Virtual Machine from the restored disks.

To attach the disks to an existing Virtual Machine, follow these steps: https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-attach-disk-portal#option-2-attach-an-existing-disk.

If you want to create a new Virtual Machine with these disks, follow these steps: https://docs.microsoft.com/en-us/azure/backup/backup-azure-vms-automation#create-a-vm-from-restored-disks.

 

Restore Option 3: Direct File Recovery

But let’s say you don’t need to perform a full VM restore, but only need to recover some files.

Thankfully, Item Level Recovery is built into Azure VM Backup. As of this writing, this feature is in public preview, but you can still check it out.

To get started with this new feature, check out this article: Recover files from Azure virtual machine backup (Preview).

This recovery option works in 3 steps:

  1. Pick your recovery point (which is the same as any backup/restore functionality)
  2. Download a script that will mount the VM’s drives so that you can browse them
  3. Once you have restored the file(s) you need, unmount the drives

 

From The Field

There are a few things to point out about this last option that may not be apparent at first.

Firstly, the executable that is downloaded will have the name pattern of VMName_Location_GUID.exe. For example, AzureDC1_eus_2612865223832953298_230696931824_2969bde19fd14d6095e58fc30f1ccb4aa1f8d3ee837e4ae203e555e96d64c.exe

Obviously, since it’s an EXE, you’ll need Administrative credentials to run it.

Secondly, please take note of the message provided with the EXE: “This script will mount the disks from the selected recovery point as local drives on the machine where it is run. These drives will remain mounted for 12 hours.“

So, a couple of things to point out here.

  1. You can run this EXE script from any system, it does not have to be the originating system. Therefore, you could run it from your Administrative Workstation, locate the files you need to restore, and copy them onto the target system as required.
  2. These mounted drives will only remain mounted for 12 hours. Meaning, if you’re using this process as part of a restore operation, but are reliant on another individual to locate the file, etc. there is a time sensitivity.
  3. If the source Virtual Machine uses Storage Spaces, you cannot run this script on the same VM. You will need to run it on a different system.

Finally, and this may or may not be apparent, but the system from which you run the EXE script must have Internet access. This is an important point to mention because depending on your Azure architecture (i.e. Virtual Networks, Network Security Groups, etc.) your source system may not have Internet access.

It is very common to have policies and controls that do not allow most servers access to the Internet. In that scenario, if you are trying to do an Item Level Recovery you will need to run the EXE script on a different system (like a Workstation), and copy files back onto the target system.

If your environment is extremely locked down, you may consider creating a non-domain joined Virtual Machine (in Azure of course), with Internet access, as your “Restore Operations VM”, and use that for any/all Item Level Restore operations.