Azure Backup Instant VM Recovery and Large Disks
This post will discuss some recent improvements that were announced for Azure Backup, making backups more efficient, large VM restores faster, and enabling support for virtual hard disks that are larger than 1TiB (1024GB).
Large Virtual Machine Challenges
One of the nice things about the cloud is cloud-scale. We can build more and bigger. Rcently, we’ve been going through a transition phase in Azure, especially with Azure virtual machine storage. A virtual hard disk was limited to 1TiB (the computer alternative to TB, which was hijacked by marketing people and rounded down to 1000GB). Today, we can deploy (in preview) 4TiB disks for Azure virtual machines, which means we can deploy some very big machines.
And that causes a problem. The process of backup is a file copy, typically over a network, to another, lower cost, storage system. If virtual machines become bigger, then the process of backup takes longer (annoying, but not too bad. Restores take longer too (pretty troubling). More importantly, until recently, Azure Backup did not have the ability to protect virtual machines with disks that were larger than 1 TiB.
Larger Than 1TiB Disks
Azure Backup has rolled out support for virtual machines with large hard disks, larger than 1TiB. This means that you can deploy machines with huge amounts of storage and protected by using the backup.
A virtual machine backup has two phases:
- A snapshot of the virtual machine’s disks is created.
- The snapshot is copied across the network to the recovery services vault. (The backup is stored.)
These snapshots will be retained at the storage cluster, where the virtual machine disks are kept for seven days. Retaining snapshots will allow Microsoft to compute changes from the last backup job more efficiently and should reduce the time it takes to complete a backup.
Don’t worry; the snapshot is still copied to the recovery services vault to ensure that you have safe long-term backups.
If you restore a virtual machine from a recovery services vault, the disks must be copied from Standard tier (HDD) block blob storage, across the network, and to the storage cluster where the disks will be kept after recovery. It can take quite a while to complete that operation. Considering how long that might take if a virtual machine has 8 x 4TiB data disks … a 32TiB data copy across a network.
Azure Backup will now leverage the seven days of backup snapshots that are being retained on the storage cluster. If you are restoring a virtual machine from the last seven days, then you can do so from the snapshot. The process will be much faster because there is no need to copy data across the network from the recovery services vault.
Instant Recovery Point
Remember that the first step in creating a backup is to create the snapshot, which is then (step 2) copied to the recovery services vault. Once the snapshot is created, you can use that snapshot to restore the virtual machine, even before the backup job has completed the data copy to the recovery services vault.
Distributed Disks Restore
If you are using virtual machines with unmanaged disks (you really should upgrade now), then previous restores would recover all disks to a single storage account. Azure Backup is adding a capability to restore the disks to different storage accounts, helping you manage storage/capacity issues that are inherent with storage accounts, especially when using Premium tier disks (SSD).
Accessing the Preview
Your backup infrastructure will require an upgrade to leverage these new features; this upgrade is non-disruptive and one-way only.
Note that the upgrade takes two hours. If you start it on one recovery services vault, then all vaults in the subscription will be upgraded.
A banner in the recovery services vault will link you to the start of the process:
If you click that banner, then a new Upgrade To New VM Backup Stack blade will appear:
Click Upgrade and the new features are registered with your Azure subscription. Approximately two hours later, you’ll have the new functionality.