I recently blogged on Petri.com how you can configure backup of Azure virtual machines. This is a superb addition to Azure, making it ready, in my opinion, for production VM hosting.
The Way it Was
Previous to the addition to this feature, there was no way to backup a running Azure virtual machine in Azure as a complete VM. There were some bad hacks:
- Storage snapshots: You could shut down a VM and snapshot the the storage account. This sucked. I’m pretty sure it wasn’t supported.
- In-VM backup: You could deploy an agent into a VM and backup files and folders. This sucked too. Microsoft tried to push DPM sales with this, requiring one Datacenter SML for every 8 VMs.
What we needed was what we could do on-premises with Hyper-V or vSphere; we needed a per-VM mechanism for backing up an entire VM, with the ability to quickly restore that VM compete with OS, applications, and data.
And that’s what Azure Backup for VMs gives us.
The Way it is Now
Now we can:
- Discover VMs
- Register VMs
- Protect VMs with policy, with up to 1 backup per day and up to 4 weeks retention.
The backup of Azure VMs is managed from the Azure portal. You get logs as well. There is no need to install or manage anything in the guest OS. A backup extension is automatically added to the VM when you protect it.
The entire VM is backed up and can be restored. Note that in terms of pricing:
- Each VM is an instance
- The size of the instance is the size of the virtual disk, not the size of the contents. So a 127 GB VM with 50 GB of contents is 127 GB, falling into the 50-500 GB instance bracket. This is different to Hyper-V, where it is the physical size that is counted (including checkpoints).
If you want granular backup then you can also deploy the Azure Backup agent into the guest OS. Note that this requires another instance and you will only be able to backup files and folders with this additional backup, which is managed from the MARS agent in the guest OS.
Note: I have talked to one of the Azure Backup PMs and he told me that there is no support for VM Generation ID. That means that you should not, ever, in any scenario, restore a virtual domain controller if there is more than one DC (the one you want to restore) in that forest.
I decided, after experimenting with Azure websites, that I wanted to retain 100% control over my website hosting. My site (WordPress) is hosted in an A2 VM and I run MySQL in the VM. This gives me the flexibility to add more sites to the VM and re-use MySQL. I don’t have any of the limitations that the ClearDB MySQL hosting has in Azure.
I configured a daily backup to run and to retain 4 weeks of data. The first backup ran last night with no issues:
I also have installed the Azure Backup agent into the guest OS. There I run a script to export MySQL to a file, and I backup this file and the IIS website folder. So in the event of a screw-up, I have the ability to restore:
- Individual website files
- The MySQL databases
- The entire VM