The number one rule in disaster recovery is to keep a copy of your resume off site.  Number two is test backups and recovery.  An unrecoverable backup is useless and a disaster is no time to find out something went wrong.  This is a second part of a previous post on encrypting Windows hard drive in Azure.  The first part is available here.  In this post I will go over how to backup and recover encrypted Windows Azure VM using Recovery Services Vault.

Before we begin

This would not be a complete post without qualifications and cautions to start with.  First, much of the post below comes from the Microsoft document here.  There is a lot of good information in this document and I suggest taking a look.

This post will skip configuration and implementation of the Recovery Services Vault for brevity.  This post assumes you have a Recovery Services Vault setup in the same region as the VM you want to back up and are successfully backing up non-encrypted VM’s.  If you don’t have this setup you can start from here.

My previous post here indicates there is some conflicting information on the need for a KEK to recover a VM or if a BEK only will work.  This post will stick with the KEK method only.  And for the record, I’m using non-managed disks.

Permissions

Before you can restore a server, you must back it up (thank you Captain Obvious).  Backing up encrypted servers is the same as non-encrypted servers with one important exception; the encryption keys need to be backed up with the virtual hard drive.

The encryption keys are stored in the Key Vault.  In order for the Recovery Vault service to back them up, it needs read access to the Key Vault with those keys.  The following steps will give the Recovery Vault service access to the Key Vault that has the keys.

First, log into Azure and open the Key Vault that has the Keys used to encrypt your VM.  From there, go to Access Policies and Add New.

Under Select Principal, search and select Backup Managed Service.  Next, go to Configure From Template (optional) and select Azure Backup.  In the end, it should look like this:

Backup

Next, Backup those encrypted VM’s.  The Azure Recovery Vault now has access to the keys and will back up the keys along with the server.  Servers can be backed up from the Recovery Vault or from Backup under the server blade or by schedule just like a non-encrypted server.

Restore, the bad news

This is where things get interesting.  For non-encrypted disks, you have three options to restore VM’s as outlined in the articles below.  They include creating a new VM from backup, restoring disks or recovering files.

https://docs.microsoft.com/en-us/azure/backup/backup-azure-arm-restore-vms
https://docs.microsoft.com/en-us/azure/backup/backup-azure-restore-files-from-vm

But this post covers VM’s with encrypted disks and as it turns out, options are limited.  The only option available is to restore the disks to a storage account.

Restore, the good news

Although some of the options are missing, such as file level restore, it’s not that difficult to recover an encrypted VM.  Start by restoring the disks from a recovery point.  Once the disks are restored a new VM will be created from those disks.

The following steps will require a Storage Account to recover the disks to.  Consider using a dedicated Resource Group and Storage Account if the recovered VM will be temporary.  This will simplify removal of the VM and associated resources when finished.

Go into the Recovery Services Vault and navigate to the Backup Items, Azure Virtual Machine, and select the VM you want to recover.

At the top of the server selected in Backup Items, select the option for Restore VM.

The Restore blade will open and you will be prompted to select a recovery point.  Select the point in time you want to recover from and click OK.

A note about Date Consistency:

There are three consistency options for the VM recovery points.  Below is a brief description of each.

• Application Consistent –  Application aware backup.  The VSS writers take action to verify application related data is consistent before the VM snapshot takes place.
• File-System Consistency – File system backed up, but application aware VSS writers have failed.  Files recoverable and VM bootable, but applications may need additional verification
• Crash Consistency – Not VSS based.  No guarantee of consistency of the data.  Similar to a hard crash of the OS.

Next, select the storage account you want to recover to and click Restore to start the restore process.

The only Storage Accounts available for recovery are in the same region as the source VM.

The restoration process will take some time.  The progress can be monitored from Backup Jobs in the Recovery Services Vault.  The Backup Jobs blade only shows active jobs in the last 24 hours by default.  To see all jobs, select the filter option to show All Status, this will include jobs that have finished.  Change the date to view jobs over a longer time period.

Create the recovery VM from the Azure Portal

This is by far the easiest way to recover an encrypted VM.  But with ease of use comes some limitations.  A VM can only recover to storage accounts in the same region as the source VM.  This makes sense as the Recovery Vault and the VM have to be in the same region.  Recovering an encrypted VM to a different region would involve migrating keys to a new Key Vault.

First, identify an existing Resource Group that the recovered server will go into.  This will likely be the same Resource Group you recovered the disks to.  Also,  create an Availability Set in the Resource Group if one doesn’t already exist.  An existing Availability Set is needed to complete the recovery deployment.

Go back to Backup Jobs in the Recovery Services Vault.  Find and select the Restore Operation that you just ran.  Remember to change the filter option if you don’t see the recovery job you want to restore from.

Select the restore job and click on Deploy Template from the Restore blade.

Fill out the required information on the Template deployment, including the name, resource group and Availability Set.  The Availability Set must already exist or the deployment will fail.  Also, the Resource Group and Availability Set should be in the same region that the original VM.  Agree to the terms and click Purchase to deploy.

although this process should work without issue, you may want to copy the template and the parameter JSON file local and run a New-AzureRMResourceGroupDeployment.  If the deployment fails, PowerShell will give you a details error message and re-running the job is much quicker.

Verify

If all goes well, the server should be deployed and will start automatically.  Verify the server starts and is accessible.  Once running, the JSON files in the Blob Storage Account where the disks were recovered can be removed.  These files were used for the recovery deployment and will not be needed after the VM is recovered.

Keep in mind that although the Azure VM name may have changed when the server was recovered, the .VHD is still a point in time copy of the source VM.  The server name and system ID’s will be the same as the source VM.  You may need to bring the server online in an isolated network and run Sysprep, or remove and re-add to the domain to prevent duplication machine issues if the source server is still on the network.

What about a single file recovery?  Unfortunately, that’s not as easy to do as it is with an unencrypted disk.  As an alternative, bring a recovered VM online long enough to grab the files you need and remove it when finished.  It would help to recover the VM to a dedicated, temporary Resource Group and Storage Account to make cleanup easy when you are finished.