VRO v6 and (now v7 as of last week) have added some major functionality to the platform, most of which can be described in 3 categories.
- Agent DR – Ability to recover from physical, agent-based backups
- Clean DR – Adding the ability to scan backups for ransomware before they are released into a production environment.
- Cloud DR – Automated recovery of agent and VM backups into Azure
This post will be focused on the 3rd category, Cloud DR. Specifically, I want to talk through the nuances of repository management when recovering into Azure. These choices can drastically impact your ease of operation – but most importantly those ever-precious RTOs.
Veeam ALWAYS recommends having a backup or backup copy on a repository local to any place you would target for a recovery. This is for one primary reason – speed and reliability of recovery. Simply put, the closer your backup files are to where they recover, the faster and more reliable the recovery. If you try to recover from a different physical location, you’re relying on the speed and reliability of the WAN (which on a good day, McDonald’s ice cream machines can be more reliable). In almost all cases you have lower bandwidth to recover over, plus having to keep those prayers going that the WAN doesn’t cut out on you. As the old saying goes, “You can’t out-code physics.”
Recovery to the cloud is no different. If you want the fastest and most reliable recoveries in the cloud, you need to have a copy in a cloud object repository. Here’s a great side by side example of what I mean:
Here we have the results of a restore into Azure from a Cold-Tier Azure Blob container. 100MB/sec with a disk recovery in less than 3 min – not bad. On the other hand:
This is a recovery of that exact same disk from a local repository on-prem into Azure. Without an Azure Express Route (which costs some serious $$), your recovery speed dips significantly. At this rate above, the recovery will take about 3 hours and 3 minutes. Compound this across more data and more machines and you’ve got yourself an angry CEO. Ouch.
So how do we ensure we are recovering from the correct repository when using VRO to recover into Azure? Let’s talk through the options, and which one is preferable IMO.
Best Option: Backup Copy using Direct to Object into Azure
From an ease of management standpoint (you’ll understand what I mean later), using a Backup or Backup Copy to Azure is the simplest way to ensure recovery will happen from Azure. The reason – it all boils down to the Recovery Locations. For recovery from backup, Recovery Locations are the central mechanism in which specifies exactly where you’re recovering to, and it’s no different with backup to cloud. So…how do we set this up?
To start, we have a standard backup copy job set to copy out to an Azure Blob storage target we intend to recover from. Pretty simple so far? Well, it gets easier!
Above, you can see in the creation (or editing) of our Cloud Recovery Location, you can specify exactly which repository you want to recover from in the “Repositories” step. So, select the repository we chose in the backup copy job, and finish creating (or saving) the Cloud Recovery Location.
Now, all it takes is creating an Orchestration plan and defining the Recovery Location we created targeting the repository from the BCJ. Now when this Orchestration Plan kicks off, you’re recovering quickly straight from Azure! It’s really that simple.
What about Scale-Out-Backup Repositories (SOBRs)?
A lot of you may be asking…what about Scale-Out Backup Repositories? What If I already have a copy in the cloud I want to use, or prefer a SOBR? You may not have budget for a 4th copy using the BCJ method described above, or simply don’t want to do a backup copy job to Azure when you already have invested time, energy, and money into setting up a SOBR with an Azure Capacity Tier.
Because Veeam sees SOBR’s as a single logical container for multiple repos, VRO doesn’t currently have the logic to specify the Capacity Tier for recovery. This is what makes recovery using a SOBR a bit more complicated. But fear not – we have a workaround!
Let’s set the stage first. Below, you can see we have created a different Cloud Recovery Location that recovers from a SOBR that has an Azure Capacity Tier. Notice how we don’t have the ability to specify the Capacity Tier for recovery operations in Azure (yet…😉)
The answer? Put the performance tier of the SOBR into maintenance mode (see below). By setting the perf. tier in maintenance mode, Orchestrator will recognize it’s offline and move to the next available copy…aka – the Capacity Tier in Azure! (See Below)
You can see after the Orchestration Plan is kicked off, VRO bypasses the performance tier and automatically reverts to the closest Capacity Tier restore point to the selected time.
Caveats to SOBR workaround
As I prefaced, using a SOBR for cloud recovery isn’t the ideal choice. You have some extra steps to take, but also putting the Performance Tier into maintenance mode has some consequences.
As shown below, the plan will flag a warning upon completion of the plan. So it won’t show on the reporting as “complete with no errors” even though it’s restored properly.
Most notably, you can’t back up to the SOBR until that Performance Tier is taken out of maintenance mode. This caveat can really disrupt normal backup operations if you have a significant amount of data that could take days to recover. While that Orchestration plan is running, you would need to keep the Performance Tier in maintenance mode the entire time to prevent VRO trying to restore from the on-prem repository. But, in a disaster situation, that may be the best option you have.
Lastly, you have put that Performance Tier into maintenance mode through VBR and not directly out of VRO. Normally, you would have to go and do this manually. However…we can automate that using the customization available in VRO! Veeam’s very own Marty Williams has created scripts that will automatically put the target SOBR’s performance tier into maintenance mode during a Cloud Recovery, and subsequently remove it from maintenance mode the moment it’s complete. Not a bad workaround for the workaround 😉.
The Results – Cloud DR is powerful.
Using the power of restoring straight from an Azure repo, recovery to the cloud can not only be quick but is completely automated! Simply press the start button on the Orchestration Plan, and in a short bit of time you have VMs spun up ready to go in Azure (see below).
Veeam automatically registers the VM, selects the machine type you need to spin the VM up based on its specs, restores the disks, creates the NICs, and registers it into the Resource Group of your choice. In literally one click, you can spin up an application or an entire datacenter into Azure that wasn’t previously there at all. That combined with restoring straight from an Azure Blob can create some serious, Enterprise-grade RTOs while minimizing costs. It’s an incredibly powerful combination.
Before you go: Azure conversion duration
Just a little FYI before I sign off – it is very common for the conversion process of automatically creating the VMs, disks, NICs, and assigning it to the proper resource group in Azure to take longer than the actual recovery of data to the disks. My lab was no exception (see below).
If you perform these cloud recoveries, you can expect the conversion to be the longest step in the process unless you have some larger disks. If you find yourself in this situation – fear not! The conversion process does take time, but the alternative of having to do this recovery process manually without VRO would take much longer (and is prone to more mistakes!).
Thanks, and hope this helps you on your journey to unlocking the power of VRO!
