History of Azure Backup
A Brief History of Backup
Why do we backup data? It’s a simple question but one that is guaranteed to give you a number of different answers. It’s also likely to open a debate between the line drawn between backup and disaster recovery. I guess in its simplest answer the main reasons we backup are:
- Because we don’t want to lose data in the event that we either accidentally delete something and now we need it
- We have some form of corruption of some data
- We have a loss or a system that held our data or (more recently) we’ve had ransomware encrypt our data
How do we back up data?
There are also a number of ways to back up data, ranging from backup to tape or Virtual Tape Libraries (VTL), Backup to Disk and more recently the concept of backup to cloud. It also depends on where your data resides and on which platform it resides as to how and what type of backup you use and where you store the backup. In many cases a backup is stored close to data for a short period so that you can do faster restores. You also need to keep copies of that backed up data in a separate location for a longer period of time. This might be to maintain compliance with regulatory requirements, or to cover the required recovery time that you expect data restore requests.
A bit of history about the changes that have happened in the last 20 years. We backed up to tape because it was cheap in comparison to disk storage. However tapes are a bit finicky and like a controlled environment without too much moisture or heat, plus the technologies were often unreliable (hands up anyone who had to wrestle with matching firmware and drivers on Netware using Backup Exec). We also had complex retention requirements to store different data onto different tape because ‘data type A’ had to have a different retention before over write to ‘data type B’. After Hard Disk Drives (HDD) started to become cheaper we started putting some backup to disk and some backup to tape for off-site. This was an improvement because disk was fast and meant we had a shorter time period in which we were affecting the data we were protecting, but the tape issues were still there. After this we started seeing more ‘disk to disk to disk’ style backups with different lower cost disk tiers, but getting this off-site over slower links was a challenge.
After all of this – the whole point of a backup is to be able to restore data from within that backup in a simple and timely manner.
What can we do now?
Now that disk seems really cheap and fast Internet links are plentiful (caveats to both of those), we now have the capability to backup to cloud services such as Azure. There are a couple of different Azure recovery services that you can use depending on where you are protecting data to help you move backups to Azure.
Using Azure Backup Server you can have a disk based backup of your data (down to as low as 15 minute intervals for application data) in a VM on premises, or in a hosted environment that is close to the data that you are protecting. You are then able to on the Azure Backup Server in the same application in a very integrated way, extend the backup to an Azure Recovery Services Vault on a daily/weekly/monthly schedule for up to 99 years. This fits well when you need fast restores for recent data but also need long term backup off-site at a lower cost.
You can also bypass the Azure Backup Server VM if you have a fast enough internet link and back up data directly to Azure. There are of course some limitations to the regularity of backups and the type of data that you are able to protect. Ultimately this can work in conjunction for data types that don’t need a local cache for fast restore or the restores you need to do are going to be small. Again this backup can be configured for retention up to 99 years.
The third option with Azure recovery services is the capability to protect Azure VMs that are running as IaaS on Azure. The backup uses an extension installed onto the virtual machine rather than an agent to backup data. Snapshots and integration with VSS are used to ensure application level consistency in backups is achieved. Again retention for VMs using backup policies enable protection for up to 99 years.
All three methods use the Azure Recovery Services vault to store the backup data in Azure. Each Recovery Services Vault can allow up to 50 Azure Backup Servers, 50 individual servers backing up directly to Azure, or 1000 Azure virtual machines to be backed up. Each Azure subscription can have up to 500 Recovery Services Vaults per region, so you’ve got some capability for expansion before needing to create another Azure subscription. There is a good article outlining the FAQs here https://docs.microsoft.com/en-us/azure/backup/backup-azure-backup-faq
What we haven’t covered in detail here is using Azure Storage for other third party backup solutions as an off site or long term backup repository. Some of those solutions integrate very nicely and have value adds that might provide a solution that means you don’t have to throw away an investment or learning in a current backup solution, but rather extend to use Azure for backup.
The next evolution of backup using Azure Cloud is flexible and ready for you to start using now!