VRO: Restore in Azure, fundamentals and deployment considerations

The overall intent of this article is to consolidate major considerations when it comes to Veeam Azure Restore and integration with Veeam Recovery Orchestrator.

Azure Core Components:

• Azure Subscription: You may want to create new Azure DR Subscription specific to Veeam required components that will be utilized during a recovery.

• Azure Region: You may have multiple Regions that you will need to restore into, along with Subscriptions it's important to map this out before you deploy.

• Azure Resource Groups(RG): We will utilize Resource Groups in Veeam for placement of restored workloads and our servers that facilitate recovery actions.

• Azure Storage Account: A storage account will be required during the creation of our Azure Proxy Restore appliance and will be used for restoration of backups into Azure VMs.

• Azure Networking: Networking is one of the biggest considerations.

  • What does your network look like between Azure and on-prem and possibly other cloud providers.

    • Do you have Express Routes in place back to on-prem?

    • You will need to consider the source vSphere or Physical Networking originally assigned to your servers, and what Target Azure Networks will you select for the VMs being restored.

Veeam Core Components:

• Veeam\Azure Compute Account: As we mentioned above, we integrate with multiple Azure components and require authentication into your Azure Tenant. 

  • In-order for us to gain access to these resources from the Veeam Backup & Replication(VBR) console we will need to create an Entra ID Application.

  • This compute account will give us access to your Azure Tenant to point and deploy Veeam components during the setup process.

  • Reference: https://helpcenter.veeam.com/docs/backup/vsphere/restore_azure_accounts.html

• Veeam\Azure Storage Account: In order for us to convert protected workloads and place data in your Azure Subscription we will need to create a Storage Account which will be associate with the Proxy Appliance.

  • Reference: https://helpcenter.veeam.com/docs/backup/vsphere/azure_entra_id.html

• Veeam\Azure Restore Proxy: During the restoration of Windows or Linux-based workloads we utilize this windows-based Proxy VM.

  • Its main role is to source data from your Backup Repository, transform/convert the data into a VHD in the Storage Account you associate during the configuration of the proxy in Veeam Backup & Replication.

  • Azure Restore Proxy is configured in the Veeam Backup & Replication console, not in Veeam Recovery Orchestrator.

  • You will want the Azure Proxy as close to the restore destination as possible, if you need to recover to different subscriptions or regions, place a proxy in each. 

  • Note: You can have multiple Proxy servers and multiple proxy servers can be utilized during recovery orchestration. 

    • You may want to select bigger compute VM Sized Proxy VMs here as the proxies are turned off until they are needed for restore.

  • Reference: https://helpcenter.veeam.com/docs/backup/vsphere/restore_azure_proxy_config.html

Veeam Recovery Orchestrator:

• It's important to note that for Veeam Recovery Orchestrator(VRO) we are utilizing components created and configured from the Veeam Backup & Replication interface, such as the (3) above. 

• Veeam Recovery Orchestrator is an additional product and deployment on top of your existing Veeam Backup & Replication server, it connects to your Enterprise Manager and/or VBR instances and creates orchestration overlays.

  • VRO Placement: If your DR is in Azure, we would recommend that this be placed in Azure or at a Witness location, preferably at the same location as the Veeam Repository you are restoring the data from during a DR Failover event.

  • Additional considerations: Veeam University (VU) https://veeam.looop.co/topic/834185

• Recovery Locations: We create and Utilize these in VRO to pinpoint the resources we are going to utilizing during a recovery event. Some of the selections include source data and placement of converted workloads. (Subscription, Region, RG, Proxy, VM Size, and Networking.)

  • Reference: https://helpcenter.veeam.com/docs/vro/userguide/adding_cloud_locations.html

• Recovery Plan: A recovery plan is where we select the workloads we will orchestrate and the Recovery Location in which those workloads will be recovered to.

  • Reference: https://helpcenter.veeam.com/docs/vro/userguide/cloud_plan_name.html

• VMware Tagging: A popular but very important aspect of our Veeam product when grouping and categorizing workloads to protect and in this case grouping of servers for restoration.

  • You will go into more depth below as their are some product design considerations for grouping servers.

  • But in general, with Veeam Recovery Orchestrator mapping and grouping your workloads for orchestration, it's best practice to-do so with VMware Tags.

How does Restore to Microsoft Azure Work:

• Now that we've dove into understanding of all of the fundamental things that make up the landscape of Restoring to Azure, we can now incorporate these into the how-to.

• Below you will find an image taken from our User Guide(UG) that gives an overview of restoring Windows Workloads into Azure.

• Step 1: Turn on the Azure Proxy

• Step 2: Data taken from the Backup Repository, converted into VHD format for the Storage Account.

• Step 3-8: Here we are mounting disks for injection of drivers, windows firewall modifications, Azure Agent installation, and unmounting the disks.

  • This process is simply to give access to the VM for these remote calls, majority of the data movement and processing stays in the cloud.

• Step 9: Azure Proxy put into standby for next workload, otherwise it's powered off.

• Step 10: Registration and Power on the new Virtual Machine is completed.

  • Reference: https://helpcenter.veeam.com/docs/backup/vsphere/restore_azure_hiw.html?zoom_highlight=azure+helper

Veeam Backup Repository location: (Restore Source)

• One of the most important design aspects is the location of the backup data in which you plan to restore from.

  • The best option here is an Azure Object Storage Cold/Hot tier blob. 

  • Other repository types are acceptable, but WAN networking latency and data rehydration will be a major consideration. 

    • Pulling from a Data Domain appliance which needs to rehydrate globally deduplicated data could add major RTO latency.

• James Janney has already written a fantastic article about the restoration of data utilizing a Backup Copy Job (BCJ) of data in Azure Object Cold Storage vs On-prem.

  • He also details out utilizing SOBR as a source repository and nuances around ensuring restoration of data from the Capacity Tier here: https://community.veeam.com/vro-heroes-den-120/vro-cloud-dr-repository-management-6225

Grouping like VMs for Orchestration:

• As we mentioned earlier, there are a lot of considerations for how you want to group your VMs.

• VMs are grouped with VMware Tags, and we want to group VMs based on the location we are going to recovery them. (Recovery Location)

  • We use VMware Tags in Recovery Plans that are linked to Recovery Locations.

    • Remember that Recovery Locations make up the Subscription, Region, RG, Azure Restore Proxy, VM Size, and Networking.

    • Recovery Plans are groupings of VMs associated to Recovery Locations.

    • You can see this represented by all the Wizard steps in creating a new Recovery Location in the images below.

• One point we want to drill into a bit deeper here is VM Size or VM Configuration.

  • In the Recovery Location we specify (3) different Azure VM Size Configurations for the recovered VMs. (See images above)

  • This configuration is important for design of your VMware Tags and Recovery Plans as you then only have (3) potential sizing options for VMs.

  • Each VM configuration (Size) can be manually associated to those Orchestrated VMs by modifying the already created Cloud Recovery Plan.

    • Note: Modifying the Create Cloud VM Plan Step in the creation of a new Cloud Recovery Plan simply modifies the Default VM Configuration for that plan.

  • In the Home Dashboard of VRO we select Recovery Plans on the left hand navigation pane, click the newly create cloud recovery plan (Blue Hyperlink) then follow the images below to modify the Create Cloud VM Plan Step and finally select the VM Configuration size for each individual VM.

• In the end of the day when it comes to grouping VMs for recovery you not only want to think about just interdependent VMs, but also the sizing of these VMs.

• One example from the field might be building a Recovery Locations specific to Subscription and VM Sizes (Location Name: SUBJTR01-EAST-Dv2-Dv4-Fsv2)

  • You can only select a single Recovery Location per Recovery Plan, but a Recovery Location can be used in multiple Recovery Plans.

Closing:

• Note: This is a live recovery and should be taken at your own risk, Veeam is not responsible for any production outages or loss of data for your recovery configurations and actions.

Recovery_Workbook: https://docs.google.com/spreadsheets/d/1qyZHWLFMg64q9CfQ3Ohnv1gRWNzT9LSzpW7L8JKkCEQ/edit?usp=sharing