Why should I care about an Azure Virtual Machine Backup and how to set it up!

 

Dear Azure Friends,

 

In this article, I am concerned with gaining attention when it comes to responsibilities and misunderstandings. The following customer statements:

"The virtual machine is hosted in Azure, so the responsibility lies with Azure".
"I pay for the virtual machine in Azure so Azure has to take care of the backup".

 

Honestly this is absolute nonsense (sorry for this expression). There is only one answer to these customer statements: Shared responsibility in the cloud!!

 

Let's take a look together at shared responsibility in the cloud.

 

https://docs.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility

 

Now let's take a closer look. A virtual machine in Azure is infrastructure-as-a-service (IaaS). Please take a look at the intersection, we can see exactly where the responsibilities lie. Everything that has to do with physical infrastructure lies with Microsoft. The rest is clearly up to the customer. Let's take a close look => from the operating system!!!

 

Now the following customer scenario: The customer runs a virtual machine in Azure. First, some applications from third-party providers are installed and a few operating system adjustments are made. Everything is fine, after a few weeks operating system updates (including security patches) are installed. After the reboot, the system in Azure no longer appears as "Running" but "unknown".

 

So what now? Call Microsoft? Open a ticket? We have seen that the responsibility does not lie with Microsoft but with the customer! This is exactly what is regularly and often underestimated. In order to prevent this scenario from happening, it is imperative to have a backup. So that in case of emergency a recovery can be made. Of course it needs more than just a backup, that has to be handled company wide with different processes. But let's keep it simple in this example and start with setting up a backup for a virtual machine.

 

When it comes to backup, there is no way around a Recovery Service Vault.

 

Now we can customize the proposed backup policy for our needs.

 

We assign a new name and set up the schedule.

 

If you wish you can select different retention options, from weekly, monthly to yearly. You can optionally name the Azure Backup Resource Group below. Click "OK" and then click "Enable Backup".

 

The deployment is made then click on "Go to resource".

 

Now we are in the Recovery Service Vault. Here we can find the details of our backup job.

 

For some time now, the Backup Center has been available in Azure and will be the first point of contact for setting up backups in the future.

 

Here we immediately see info about our backup in the overview. In the meantime I started the backup manually (outside the schedule) so that we can look at the backup together.

 

The backup result in the virtual machine details.

 

The Backup Center shows us that the transfer to the Vault still needs to be processed.

 

Important:
The backup is the first step in the right direction, don't forget to perform a test restore regularly to make sure that your virtual machine will work exactly as you expect it to after a restore!

 

If the customer had created at least one backup, this "ugly" situation would never have occurred. For this reason it is super important to know where the RESPONSIBILITIES lie!

 

I hope this article was useful. Thank you for taking the time to read the article.

Best regards, Tom Wechsler

 

P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechsler