Azure Agent-Based Backup: Best Practices & Traffic Isolation

[wandersick]

Hello,

I love Veeam and would sincerely like to leverage it in the best way I possibly can.

As it is a common requirement to prevent backup traffic from affecting production workload, are there any best practices achieving so for Azure? That is, preventing Veeam agent-based backup from affecting production workload on IaaS VMs. (Actually I am doing this for Azure Stack but I believe the considerations are similar.)

Two ideas (scenarios) on my mind now (hope they make sense):

1. Attaching a second NIC (belonging to a backup subnet separated from production subnet) to each Azure VM. An Azure Veeam B&R server (with backup repository) also resides on the backup subnet.

To transfer the backup off-site (off Azure) with less impact, a WAN accelerator is implemented on the Azure Veeam server (with SSD Premium Storage), through which a backup copy job transfers backup files via a site-to-site VPN connection to another on-premises Veeam server and backup repository (or directly over WAN to a on-premises Veeam Cloud Connect for Enterprise server and backup repository) for long-term storage.

On the other hand, to prevent backup traffic from saturating the VPN/WAN link (which could be shared with production workload), Veeam network traffic throttling rules are configured. Also, QoS rules are configured on client devices (e.g. marking Veeam traffic as 'bulk').

2. As the above (scenario 1) involves a Veeam server and backup repository in the Azure, I would like to eliminate that to save capacity or cost (on additional processing, SSDs and storage capacity, etc. due to our massive amount of workload). It means there will only be an on-premises Veeam backup server and repository towards which backups from Veeam agents on Azure are transferred.

This sounds like a lot of traffic without WAN accelerator, but we will still leverage Veeam network traffic throttling rules and QoS rules to minimize the impact.

Moreover, each Azure VM will still have a second NIC connected to a backup subnet.

In the same backup subnet on Azure, we will implement a Veeam gateway server to proxy traffic to the on-premises Veeam server/backup repository over the VPN/WAN link (does that make sense?) so that production workload are least affected by backup traffic. (i.e. the settings of the on-premises Veeam backup repository, towards which Azure Veeam agents points, specify a Veeam gateway server located on Azure.)

------------
How do the two plans sound? Please correct me in any parts that I am wrong.

For example:
- Are there better/more ways to separating the backup traffic from the production workload?
- Is there any way to improve the scenarios (especially scenario 2 which we consider)?

(Sorry if this has been answered before or considered basic)

Any input would be much appreciated. Thanks a lot.

[Dima P.]

Hi wandersick,

Thank you for the kind words and Happy New Year!

You can protect your Azure VMs with agent policy (managed by agent job) aiming Veeam B&R repository as a target. If possible, you can setup a local Azure repository, add it to Veeam B&R and use this repository as a destination for managed by agent job (agent policy). With this setup backup traffic should be isolated in Azure, however management traffic remains. Then you can use backup copy to pull backup files from the cloud to the ground.

Regarding agent deployment – you can assign a distribution server role to the same server that acts as Veeam repository (should be a Windows host). Agent installation pack will be uploaded to the distribution server once and then this server will be used to deploy backup agents. With this approach you isolate the setup traffic as well.

[wandersick]

Thank you very much for the fresh tips on new features of the recently released B&R 9.5 Update 3

You can protect your Azure VMs with agent policy (managed by agent job) aiming Veeam B&R repository as a target. If possible, you can setup a local Azure repository, add it to Veeam B&R and use this repository as a destination for managed by agent job (agent policy). With this setup backup traffic should be isolated in Azure, however management traffic remains. Then you can use backup copy to pull backup files from the cloud to the ground.

Unfortunately, as mentioned previously, to simplify the infrastructure, we might consider not implementing the local Azure repository, but an on-premises CIFS repository only, i.e. my previous scenario 2, in which all agent backups will be proxied by one or more Veeam gateway servers located on Azure over a site-to-site VPN connection down to the on-premises CIFS repository (i.e. without using a backup copy job through WAN accelerator described in scenario 1).

Please refer to this simplified illustration of the cross-premises backup traffic flow of scenario 2:

(BTW, the reason for adding a second NIC to each production VM is for separating backup traffic from production traffic due to the lack of direct VM access modes such as hot-add or direct SAN in agent-based backup. Please let me know if there is an alternative, however.)



(Note: Only backup traffic is illustrated; production traffic also passes through the VPN gateway.)

However, according to the Veeam gateway server documentation, "in the common case, a machine to which you assign the role of a gateway server must be located as close to the backup repository as possible." Although the Veeam gateway server (on Azure) is a little far away from the (on-premises) repository, I think the above is still a better design (please correct me if I am wrong) than not having a Veeam gateway server on Azure managing the backup traffic from Veeam agents (of different Azure VMs) before transferring it down on-premises.

Reference (Gateway Server): https://helpcenter.veeam.com/docs/backu ... tml?ver=95

Any comments (e.g. on whether that is feasible) would be much appreciated. Thanks.