Hi folks! My name is Felipe Binotto, Senior Azure Customer Engineer, based in Australia.
The purpose of this article is to demonstrate how you can have different Backup Tiers for your VMs and how you can automate the backup configuration leveraging Azure Tags and Azure Automation.
The prerequisites are:
- Automation Account
- Az.ResourceGraph module must be installed
- Az.RecoveryServices module > 5.4.0 must be installed
- Runtime version 5.1 (it should also work with 7.1 but it was not tested)
- Recovery Services Vault with system or user managed identity
- If you have many Recovery Services Vaults, you should create a user managed identity so it can be used across all of them, and you just have to set permissions to one identity
- This identity should be assigned Backup Operator and Virtual Machine Contributor roles
- Virtual Machine
Now you are thinking, why do I need multiple Backup Tiers?
Imagine you have two workloads. Workload-1 is business critical, and it can only afford losing up to 4 hours of data and it should be fully recovered in no longer than 24 hours. Backups should be retained for a minimum of 90 days. Workload-2 is important but not that critical so it can afford losing up to 12 hours of data and it should also be fully recovered in no longer than 24 hours. Backups should be retained for a minimum of 30 days.
So, what do you do? You create two Backup Policies. One for each workload based on their requirements. Each workload has its own RPO/RTO and retention requirements.
Let’s say you have analysed all your workloads and established that most of them will fit in one of the following tiers.
|
Tier |
RPO |
RTO |
Retention |
|
TIER-1 |
4 hours |
1 day |
90 days |
|
TIER-2 |
6 hours |
1 day |
60 days |
|
TIER-3 |
12 hours |
1 day |
30 days |
|
TIER-4 |
24 hours |
2 days |
15 days |
Note: although we are specifying RTO in this example, the focus is RPO and Retention, because RTO will depend on other factors such as size of backup (the larger the backup the longer it will take to restore) and backup availability (LRS vs ZRS vs GRS).
Azure Backup for VMs
Virtual Machines in Azure can be backed up to Recovery Service Vaults. When you are preparing the VM for backup, you must select a Backup Policy which defines how often the VM should be backed up, what is the retention period and other settings.
Until recently, you could only configure a Backup Policy to perform the backup once a day. However, now you can use the new Enhanced type of Backup Policy, currently in public preview, to set backups to be performed up to 6 times a day (every 4 hours).
The figure below provides an example on how an Enhanced Backup Policy would be configured to fulfill the requirements of TIER-1.
Backup Policies
OK, we have defined all the basics. Now let’s create all the required Backup Policies. You can download the script from my Github Repo. This script will iterate through all Recovery Services Vaults in all subscriptions and create three Enhanced and one Standard Backup Policies according to the requirement of each tier. Policies are named as per the Tier names.
The table below provides details about the policies created after the script is executed.
|
Policy Name |
Frequency |
Start Time |
Schedule |
Duration |
Timezone |
Daily retention |
|
TIER-1 |
Hourly |
6:00AM |
4 hours |
24 hours |
UTC |
90 days |
|
TIER-2 |
Hourly |
6:00AM |
6 hours |
24 hours |
UTC |
60 days |
|
TIER-3 |
Hourly |
6:00AM |
12 hours |
24 hours |
UTC |
30 days |
|
TIER-4 |
Daily |
6:00AM |
N/A |
N/A |
UTC |
15 days |
You should see the new Backup Policies in each of your Recovery Services Vaults as per the figure below.
VM Tag
Next step is to tag the VMs to be backed up. There are a few points to be considered as follows:
- VMs without tags will not be backed up
- VMs which are already backed up and are not tagged will remain with their existing backup configuration
- VMs which are not backed up and are tagged will be backed up
- VMs which are backed up and are tagged will have a new Backup Policy assigned if using the incorrect policy.
We will tag the VMs with a tag named BackupTier.
The code below will retrieve the VM objects and tag them.
$vm = Get-AzVM -Name Workload-1 -ResourceGroupName VMs
New-AzTag -Tag @{BackupTier='TIER-1'} -ResourceId $vm.id
$vm = Get-AzVM -Name Workload-2 -ResourceGroupName VMs
New-AzTag -Tag @{BackupTier='TIER-3'} -ResourceId $vm.id
Once you tag the Workload-1 and Workload-2 VMs they will look like the figures below.
Azure Automation
Before we get to the last piece of the puzzle, let me clarify something that may be in your mind. You may be wondering why using Azure Automation and PowerShell instead of using the built-in Azure Policies for Azure Backup. A few reasons for that:
- The Azure Policies for Azure Backup cannot be applied at Management Group level
- Depending on the number of subscriptions and tiers you use in your solution, you could end up with hundreds or even thousands of Azure Policy Assignments
- The built-in policies must be customized to change an existing backup policy. By default, they just enable backup based on a tag
- A policy remediation is required to enable backup for existing VMs and to change the backup policy of VMs when tag values are changed.
OK, now that we have cleared that up, let’s get started with the Azure Automation account.
Now to the last piece of the puzzle. You need to create a new Runbook and copy the code from this script in my Github Repo.
You need to provide values for the following three variables:
- accountId – the object ID for the Automation Account managed identity
- vaultRGName – the resource group name for the Recovery Services Vault
- vaultName – the Recovery Services Vault name
The last step is to run the Runbook. Don’t forget about the prerequisites listed in the beginning of the article. It will not work without those in place.
After the runbook completes successfully, you should see the following in the Output tab.
Once you are satisfied the Runbook works as expected, create a schedule based on your requirements and link it to the Runbook.
A couple last comments about the runbook:
- If the backup of a VM is in a Soft-Delete state, it will fail, and the reason will be displayed in the Outputs tab
- If the VM is using Shared Disks, it will not try to back it up as it is an unsupported scenario
Feel free to fork the repo or do pull requests if you have new features or bug fixes to be incorporated into the code.
I hope this was informative to you and thanks for reading. Add your experiences or questions in the comments section.
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.