Backing up your Azure Resource Manager VMs

Azure Backups has been GA for a long time now but not long ago, the folks at Azure just removed the preview tag from the service that handles backing up Resource Manager VMs. I’ve been testing Azure Backup on RM deployments since it was announced in preview and I can say that almost all my tests showed promising results. I’ve encountered a couple of quirk during tests but those were ironed out fast and now that the service is out of preview I can say that Resource Manager VM deployments are the way to go.

In this blog post I will show you how to configure the Azure Recovery Services to back up your Azure VMs and recover them when required.

Before we start using the backup feature of Azure Recovery Services, we need to understand how backups are being made in order to prevent any surprises when something wrong happens.

We can protect two types of workloads using Recovery Services:

1. Azure VMs

2. On-Premise Workloads

For protecting files and folders, all you need to do is to install the Azure Backup agent on the server that you want to protect on a file level but for protecting Hyper-V, SQL, Exchange or SharePoint workloads you need a dedicated machine where you install the Microsoft Azure Backup Server (MARS) and tie it to your backup vault. MARS is a stripped down version of System Center Data Protection Manager but the good thing is that the only thing missing from this version is tape backups.

Azure VM backups have three types of consistency levels:

Crash Consistent – This means that you receive no guarantee on the data consistency on the storage medium. Crash consistent backups are equivalent to virtual machines that are experiencing a crash via a soft or hard reset. This type of consistency can happen when the virtual machine is shutdown during the backup process. On a restore, the VM usually boots up followed up by a disk corruption check (OS mechanism)

File-System Consistent – This can happen in two cases. Either the backup is being done on a Linux VM and this happens because it doesn’t have VSS provider or in case of a Windows VM, it happens in case of a VSS failure. This means that in case of a restore your VM boots up with no data loss or corruption but you don’t have any guarantee on application consistency. That has to be solved on an application level.

Application Consistent – This best backup you can get. On a restore the VM boots up with no corruption or data loss and the data is consistent to the application that uses the data.

Application consistency can be achieved by using the Volume Shadow Copy service or VSS in short. Most (if not all) Microsoft applications have VSS writers. You can read more about VSS here – https://blogs.technet.microsoft.com/josebda/2007/10/10/the-basics-of-the-volume-shadow-copy-service-vss/ –

So we understand the consistency levels; What happens we do a restore operation?

Basically when you’re in trouble and need to run a restore operation, you need to take in account the fact that an in-place restore cannot be done because that feature doesn’t exist (yet?). So if you have any naming conventions in your subscription then my advice would be to delete the failed VM and its resources before you do the restore operation.

Now that we have some minimal information regarding the backup feature from Azure Recovery Services, let’s start backing up our workloads ?

First of all, you need to create an Recovery Services Vault which you can do using the portal or using the Azure PowerShell cmdlets.

Once you’ve gone through the steps of creating the Recovery Services Vault, now is the time to set up a backup policy that fits your needs. The Recovery Services Vault comes with a default policy that backs up VMs at 11:00 AM your local time with a 30 day retention which may be enough for some of you but others may need more.

You can access and create backup policies by going in the settings of the Recovery Vault. There you can create, edit or delete policies. By pressing on the add button you will get a new blade that contains a plethora of options that satisfy your backup requirements. The retention periods that you can input can be between 1 and 9999 days, weeks and years though I haven’t tried those numbers.

The PowerShell way of creating / setting a backup policy is quite complicated and from my point of view, the best way to create / set backup policies is using the Azure Portal.

Once you finished configuring all your backup policies, now is time to start backing up your Azure VMs.

All you need to do in order to backup a VM is to go to the Recovery Services Vault and press on the backup button and follow the steps from down below:

1. You need to establish the workload type. In our example we’ll use an Azure workload because an On-Premise workload needs some prep work and I may cover this process in a later article.

2. In the next step we need to choose a backup policy from the drop down menu. I suggest having multiple backup policies based on the type of workloads you’re running in Azure and how long you want those backup points to persist.

3. In this step you select the VMs that you want to back up based on the policy you just chose. After this step all you have to do is press on ‘Select’ and press on ‘Enable backup’.

From this point, a job will trigger for each VM, configuring them for the backup process and once that’s finished you can start the initial backup. Please be advised that by configuring the backup process that doesn’t mean that Azure started backing up the VMs. The initial backup will start based on your backup policy.

To initiate an initial backup process manually, you need to go to the Recovery Service Vault -> Backup Items -> select the VM and press on Backup Now.

I’ve illustrated the process in the screenshots down below.

Once you’ve initiated the first backup cycle you can now go get a cup of coffee and a donut and watch the latest episode of your favorite series because it will take a while until the backup finishes. You can monitor the status of your backups by pressing on the Backup Jobs box. The amount of information at this point in time is quite sparse but you can see a general picture of the progress.

The Recovery Services Vault supports backing up HDD, SSD series VMs and VMs that are using mixed storage (DS/GS VMs with HDDs and SSDs). F series VMs are not currently supported by Azure Recovery Services

If you want to be notified if something goes wrong with a backup then you can set up e-mail notifications. Those e-mail notifications are set at a vault level and you can type in either multiple e-mail addresses or a distribution list that will receive e-mail alerts regarding backups that went wrong so you can fix the problem as fast as possible.

When configuring e-mail notifications, you have two options. You can either get e-mail notifications on a per alert basis or on an hourly basis. The per alert basis will send out an e-mail as soon as a backup alert is raised or you can select an hourly alert that contains information about all the backups that raised alerts.

You can enable and configure e-mail notifications by going to the Recovery Services Vault settings -> Alerts and Events

Here’s how the e-mail looks like:

OK then, so you’re VMs are being backed up and everything is nice and dandy. But how do you recover said VMs in case of a reactor meltdown? Well the answer is pretty simple!

1. Go to the Recovery Services Vault and press on Backup Items and on the VM that failed and needs to be restored and press on the Restore button.

2. Choose a restore point and then fill out the necessary fields required to re-deploy the VM.
Here’s where you will find one of the differences between your on-premise environment and the cloud. When you do a Hyper-V VM restore, you have the option to do an in-place restore but with Azure that option doesn’t exist, so you’re left with creating a new VM and deleting the old one or vice versa.

So that’s that. Easy as 1,2,3 ? I would have provided a PowerShell way to accomplish everything I illustrated in the screenshots but unfortunately the Azure PowerShell cmdlets for Azure Recovery Services are not quite intuitive when compared to the point and click solution.

Have a good one!

LE: I just found out that an e-mail alert feature has been introduced, so I took the time and re-created the screenshots to provide an updated picture of the Recovery Services feature ?