As far as Azure IaaS goes, this is the biggest improvement to the platform since the ExpressRoute offering.

The announcement is here, and I highly recommend reading it:
http://azure.microsoft.com/blog/2015/03/26/azure-backup-announcing-support-for-backup-of-azure-iaas-vms/

The highlights:

• With Azure Backup, you can now get application consistent backup of Windows VMs without having to shut down the VM.
• “In order to backup IaaS VMs, the customer needs to deploy absolutely nothing”*
  Note: This is accurate insofar as you have the Azure VM Agent installed (see Prerequisites below)
• Azure Backup truly achieves “set-and-forget” for VM backups.
• Azure Backup does additional processing to determine the incremental changes between the last recovery point and the current VM state. By transferring and storing only the incremental changes, Azure Backup is highly storage efficient.

Azure VM Agent Prerequisite

• A very important prerequisite is that the Azure VM Agent must be installed. This is performed when the VM is first created, but if you uncheck the box to install the agent, then you will not be able to back it up with the new VM level backup feature.
  
• If you do not have the Azure VM Agent installed, you will get an error message during the registration job step:
  ”Failed to install the Azure Recovery Services extension on the selected item. VM Agent is a pre-requisite for Azure Recovery Services Extension. Please install the Azure VM agent and restart the registration operation.”
• You can manually download and install the VM Agent if it is not installed on the VM, see this article for more information:
  https://msdn.microsoft.com/en-us/library/dn832621.aspx
• The VM agent itself can be downloaded directly from (here) and is very small and takes seconds to install.
• After manually installing the agent, it is necessary to set the ProvisionGuestAgent value to true using Powershell or a REST call. If you do not set this value after manually installing the VM Agent, the addition of the VM Agent is not detected properly.)
• See my blog post for manually installing the VM agent for step by step instructions:
  http://tctblgs.azurewebsites.net/manually-install-the-azure-vm-agent/

Seeing it in Action!

Assuming you have already setup your recovery vault, and your VM’s have the VM Agent installed, then there are three easy steps to start backing up VM’s in Azure IaaS

After clicking on ‘Discover Virtual Machines’ you then click on the Discover button at the bottom of the screen.

After discovery completes, you then click on the Register button.

This brings you to a screen to select the VM’s that you want to protect.

Clicking on the checkmark will spawn a register job that can be viewed on the Jobs tab. In my case, this job took 4 minutes to run.

Now that we have a VM registered, the next step to perform is step number 3, “Protect Registered Azure Virtual Machines.

Select the item you want to protect

You can then select an existing policy or create a new policy

When the backup has taken place, you can view it under protected items.

You can force a new backup or you can click on Restore to bring the VM back to life as a new VM standing next to the old one (it does not overwrite the existing VM).

Restoring a backup

A backup is only “good” if you can verify it by performing a restore. Until then, you should not trust your backups. I have learned this the hard way in the trenches =)

It is interesting that when you restore a VM, it does not overwrite the existing VM, but it instead deploys it alongside the current VM.

You can check the Jobs tab to see how long the restore will take. In my case, the restore took 23 minutes.

When the restore job completes, you can view the job notes:

To view the restored VM, I had to sign out and back into the Azure Management portal, but then I saw the restored VM amongst my other VM’s:

This raises a practical operational question where you need to be sure to shut off the old one before the new one starts up otherwise in a batch environment you wouldn’t want two VM’s running the same batch (you get the idea, you need to know what your VM’s are doing and coordinate properly).

Therefore, it would be good to have an option during the restore process for Azure to automatically shut down the original VM on your behalf to tighten-up the handoff, as you want to avoid having two machines with the same computer name and SID running on the network.

For example, in my restored VM, I can see it still has the original computer name (as I would expect) and so even though the name of the VM in Azure shows as ‘MyRestoredVM’ the actual computer name maintains the original name. (This is okay behavior, but just remember we need to shut off the original VM now too). I posted this feedback on the Azure Feedback portal, please click (here) to vote if you agree and would like the Azure Product team to include this feature in a future release.