A backup policy is used to define different aspects of how you want to back up your workloads, and multiple policies can be created and used. For example, you may want to use one policy for application VMs that don’t change very often, and a separate policy for database VMs, whose data changes continually.
Once a policy has been created, VMs can be onboarded in a number of ways:
- Individually via the Backup blade of the VM you wish to backup
- In groups, by associating VMs with backup policies in the Recovery Services vault blade
- During a VM build, either when creating via the portal or when using ARM templates
- Via an Azure policy
When creating a policy, you define the policy type, choosing from either Azure Virtual Machine, Azure File Share, SQL Server in Azure VM, or SAP HANA in Azure VM.
Depending on the policy type, you then have different options around the backup schedule and retention:
From the preceding table, we can see that we have different options depending on what we are backing up. There are also a few points to consider when defining our overall backup solution.
Backup retention
The first consideration is around retention, which is the length of time any backup is retained for. We can have backups be retained for days, months, or even years; however, the longer you retain backups, the more individual backups you will have at any one time, and therefore your storage costs will increase.
Next, for databases, we can choose to configure full, incremental, or differential backups.
Backup types
A full backup is a complete backup of the database at that point in time. After the first full backup has been taken, we can opt for differential or incremental backups.
Some backup types, such as SQL on VM and SAP HANA, offer a differential backup that only backs up blocks of data that have changed since the last full backup.
An incremental backup only stores blocks changed after the last incremental backup.
Both incremental and differential backups use far less storage and less network bandwidth; however, the downside is that it can take longer to restore.
The final consideration is the frequency of our backups.
Backup frequency
We can only back up VMs on daily or weekly schedules, and a VM can only be associated with a single policy. Database backups can be more granular – by backing up logs every 15 minutes we effectively provide ourselves with an RTO of 15 minutes; however, our VM RTO is 24 hours.
If your VMs do not contain changing data, an RTO of the VM itself would be fine. If, however, your solution stores data on a VM and the RTO of that data is less than 24 hours, the backup mechanism would not cover you.
To overcome this limitation, you could re-architect your application to store such data on a different mechanism, for example, in a database or blob storage with geo-redundancy enabled.
Alternatively, you could use a different backup solution that would provide a continual backup of your VMs – Azure Site Recovery.
Leave a Reply