First impressions of Azure VM Backup
Microsoft announced the launch of Azure VM backup earlier this week: https://azure.microsoft.com/blog/2015/03/26/azure-backup-announcing-support-for-backup-of-azure-iaas-vms/ It is a feature that many of us have been waiting for so decided to give it a try on a small deployment I am currently working on. The steps below outline what I did to configure Azure Backup and some of the issues encountered.
I have included steps and screenshots as there doesn’t seem to be much documentation around and hopefully they can be used to see what the process is before diving in head first.
Creating a backup vault
This is done exactly the same way as we have done for Azure Backup in the past.
Point to note: I decided I would deploy the Backup Vault in a different region, but same “Geo” to the VMs, then we could potentially use LRS rather than GRS storage to save some cash. The blog post from Azure team says this about discovery (more on discovery later) :
“This step gets a list of all IaaS VMs in the same Geo that have not already been protected.”
As my deployment is in “North Europe” I chose “West Europe”. However, when I got to the discovery stage no VMs were discovered. I deleted the Backup Vault and recreated it in the SAME “Region”, i.e. “North Europe”, and the discovery process completed successfully. Not sure if this is a bug or an error in the announcement blog post, or a misunderstanding on my part as far as what a Geo is in Azure.
UPDATE: Microsoft have corrected their blog post, the vault needs to be in the same Region as the VM.
On the Quick Start page of the Backup Vault it shows the three main steps to configure the backup of Azure VMs:
Discover the Azure VMs
To discover the VMs, needed to click discover in the command bar at the bottom of the portal.
Here is the error I received when the Backup Vault was in a different Region to my VMs:
Once I recreated the vault in the correct region the VMs were discovered successfully:
Registering the VMs:
Before registering the VMs it is important to consider if you wish to use LRS or GRS storage. This HAS to be configured before registering the VMs. This screenshot is from my original Backup Vault where I was going to use LRS. These option can be accessed via the Configure tab:
To start the registration process visit the Registered Items tab and click on Register in the command bar. Then we get a simple tick list as follows:
Once the VMs had been selected the registration “Jobs” are started:
One of my VMs successfully registered, the other failed with the error:
Microsoft Azure Backup encountered an internal error.
Wait for a few minutes and then try the operation again. If the issue persists, contact Microsoft Support.
As seen below:
This was yesterday, I tried again today ant the error persists when I try and register this VM. I can’t see anything logged within the VM itself, so I may end up creating a support case. I will update this post whe (or more likely Microsoft) get this resolved.
Protecting the VMs:
Again, protection is accessed via the command bar, and we get a simple check list as follows:
The next step is to define the backup policy:
You have to option to select an existing policy, policies can be managed on the Policies tab of the Backup Vault. As this is my first I created a new policy. A couple of points to note are that at present you can:
- only schedule ONE backup a day
- retain data for a maximum of 4 weeks
I guess as with most things on Azure this will change, and the GUI looks like its been made to schedule multiple backups a day.
Under the Protected Items tab on the portal it showed that an initial backup was pending:
There is an option on the command bar to “Backup Now”. I tried this and a backup Job was created and the portal updated once complete.
The initial backup took around an hour and a half, then the scheduled one at midnight, took around 30 minutes. Backup time and performance impact on VMs is something I will be paying close attention to in the coming weeks.
Recovering VMs:
I am yet to go through the full recovery process, something I will likely try next week. I have however looked at the recovery option. When choosing to recover a VM you can choose a date and recovery point:
After this you are presented with an option to restore to an existing Cloud Service or to create a new one, and choose the appropriate Virtual Network:
This is where I stopped, hopefully next week I will have time to create a recovery network and test some restores. As we all know backups are no good unless we test that they actually work!
Conclusions
I’ve been waiting for this feature for a long time and it makes Azure one step closer for being a straightforward replacement for existing on premise infrastructure. The other main feature we need is VM console access as RDP isn’t sufficient to troubleshoot a VM that won’t boot.
As far as the backup functionality we do need to see more backup frequency and retention options, similar to those released recently with standard Azure Backup. I guess we could use guest level Azure Backup features to provide longer retention for selected data but there is an administration overhead that comes with that. Protection of files with a VM would also be a nice addition.
This is a new release, it interestingly wasn’t announced with the “Preview” tag, but there are a few bugs that still need ironing out by the looks of things. I will continue to test over the coming weeks and expect that these minor issues will be resolved. Either way it is a giant step forward that enables us to migrate more workloads to Azure.