How to configure and optimize proxy servers
Proxy servers are the workhorses of the Veeam Backup & Replication v11a application, and they do all the heavy lifting or processing of tasks for backup and restore jobs. When you set up Veeam, you need to ensure that the proxy servers get configured as per best practices:
- https://bp.veeam.com/vbr/VBP/2_Design_Structures/D_Veeam_Components/D_backup_proxies/vmware_proxies.html
- https://helpcenter.veeam.com/docs/backup/vsphere/backup_proxy.html?ver=110
When you decide to deploy a proxy server, Veeam Backup & Replication will install two components on the server:
- Veeam Installer Service: This is used to check the server and upgrade software as required.
- Veeam Data Mover: This is the processing engine for the proxy server and does all the required tasks.
Veeam Backup & Replication proxy servers use a transport mode to retrieve data during backup. Three standard modes are available, and they are listed in order, starting with the most efficient method:
- Direct Storage access: The proxy is placed in the same network as your storage arrays and can retrieve data directly from there.
- Virtual Appliance: This mode mounts the VMDK files to the proxy server for what we typically call Hot-Add Mode to back up the server data.
- Network: This mode is the least efficient but is used when the previous methods are unavailable. It moves the data through your network stack. It is recommended not to use 1 GB but rather 10 GB.
In addition to these standard transport modes, which are provided natively for VMware environments, Veeam provides two other transport modes: Backup from Storage Snapshots and Direct NFS. These provide storage-specific transport options for NFS systems and storage systems that integrate with Veeam.
See the integration with storage systems guide for more details: https://helpcenter.veeam.com/docs/backup/vsphere/storage_integration.html?ver=110.
Along with the transport modes, there are specific tasks that the proxy server performs:
- Retrieving the VM data from storage
- Compressing
- Deduplicating
- Encrypting
- Sending the data to the backup repository server (backup job) or another backup proxy server (replication job)
Veeam proxy servers leverage what is known as VMware vStorage APIs for Data Protection (VADP) when using all transport modes other than Backup from Storage Snapshots and Direct NFS.
You should consider the following regarding your proxy servers:
- Operating System: Most software vendors will always recommend the latest and greatest, so if you choose Windows, then choose 2022. Alternatively, you can select Linux using the latest release (Example – Ubuntu 20.04.1 LTS). Note that for Linux VMware, backup proxies support all transport modes as of Veeam Backup & Replication v11a.
- Proxy Placement: Depending on the transport mode for the server, you will need to place it as close to the servers you want to back up, such as on a specific host in VMware. The closer to the source data, the better!
- Proxy Sizing: This can be tricky to determine and will depend on the physical or virtual server. Veeam proxy servers complete what are called tasks, which is where one virtual disk is processed for a VM or one physical disk is processed for a server. Therefore, Veeam recommends one physical core or one vCPU and 2 GB of RAM per task.
Veeam has a formula to calculate the required resources for a proxy server:
- D = Source data in MB
- W = Backup window in seconds
- T = Throughput in MB/s = D/W
- CR = Change rate
- CF = Cores required for full backup = T/100
- CI = Cores required for incremental backup = (T * CR)/25
Based on these requirements, we can use a data sample to perform the calculations:
- 1,000 virtual machines
- 400 TB of data
- An 8-hour backup window
- 5% change rate
Using these numbers, we can perform the following calculations:
We can use the numbers we calculated to determine the required amount of cores needed to run both full and incremental backups to meet our defined SLA:
Based on our calculations and considering that you require 2 GB of RAM for each task, you need a virtual server with 146 vCPUs and 292 GB of RAM. This size may seem like a considerable server, but keep in mind that it uses the sample data. Your calculations will likely be much smaller or possibly more extensive, depending on your dataset.
Should you decide to use a physical server as a proxy, you should have a server with 2–10 core CPUs. In the case of our sample data, two physical servers are what you require. If you are using virtual servers for proxies, the best practice is to configure them with a maximum of 8 vCPUs and add as many as needed for your environment – in this case, we would need nine servers.
Should you want to size things based on incremental backups only, your requirements are less than half of the full backup sizing – 29 vCPUs and 58 GB of RAM.
There are limitations for proxy servers that you need to be aware of when it comes to job processing and performance. As we noted previously, a proxy server performs tasks, which are assigned CPU resources. Concurrent task processing is dependent on the resources you have available in your infrastructure and the number of proxy servers you have deployed. As shown in the following screenshot, when it comes to adding a proxy server to Veeam Backup & Replication, there is the Max concurrent tasks option, which correlates to the number of CPUs that are assigned:
Figure 1.14 – Max concurrent tasks limitation for proxy servers
Task limits can be found at https://helpcenter.veeam.com/docs/backup/vsphere/limiting_tasks.html?ver=110.
Important Note
Job performance gets impacted based on the tasks of a proxy server. For example, if you had a proxy server with 8 CPUs and added two virtual machines for backup, one with four disks and another with six disks, the proxy server would process only eight of the 10 disks in parallel. The remaining two disks would have to wait on resources before backing up.
You should now be able to right-size your proxy servers regarding CPU and RAM and understand proxy placement and how it processes tasks. Proxy servers send data to repository servers, which is the focus of the next section.