The purpose of this KB is to provide our recommendations for the use of Veeam V12.

This information was gathered from support cases as well as certification testing of Veeam V12.

The following acronyms are used in this article for clarity purposes:

• VB365 = Veeam Backup for Microsoft 365

• VBR = Veeam Backup and Replication

• VBA = Veeam Backup Agent for Windows

General Configuration Guidelines

To avoid creating buckets with too many objects and to keep bucket listing performance under control, we recommend:

1. Use large storage object size in VBR and VBA (4MB or higher)

2. A new dedicated bucket and storage domain must be used for every SOBR and workload ( VB365 backup, archive backup jobs etc ) . This will allow you to take advantage of future support for separate elasticsearch indices per storage domain.

3. Keep VB365 and VBR in different buckets, as VB365 does not support versioning or object locking.

4. Veeam backup agent (VBA) now allows direct to cloud backup, it does however not provide you with a way to limit concurrent connections via the Proxy Threads like VBR does. You will need to define this at the load balancer level. Some examples are provided at the end of this article.

5. Be mindful of the capacity requirement if your backup schedule is aggressive and rapidly deletes data. Deleting data in Swarm is not immediate; it relies on a background health process to convert deleted (trapped) space back into free space and you will need sufficient free space to ingest new data while the trapped space reclamation occurs. For more information see KB article https://perifery.atlassian.net/wiki/spaces/KB/pages/38050005

When using multiple gateways in your environment make sure to use a real load balancer, DNS round robin is not a valid load balancing configuration. We recommend using the least connection load balance algorithm.

Veeam Backup for Microsoft 365 (VB365)

VB365 only has a single way to configure the number of threads (default is 64) it uses to communicate with the backup repository.

Reference: https://helpcenter.veeam.com/docs/vbo365/guide/vbo_threads_and_limit.html?ver=70

In a mixed environment if your backup repository is overwhelmed with too many concurrent connections we recommend reducing the backup proxy threads.

VB365 stores data items in chunks to the object storage repository. These chunks are before compression 5MB for Exchange data and 8MB for SharePoint and OneDrive data. Veeam documentation says that you can assume 40-50% compression efficiency.

Source reference material: https://bp.veeam.com/vb365/guide/design/sizing/objectstorage.html

Veeam Backup Agent for Windows (VBA)

When using direct to cloud backup option, using larger block size can yield up to 3.5x faster performance. We recommend at least 4MB block size.
This is configured in the backup job properties → Bucket → Advanced (button) → Storage Tab.

Open

You can configure network throttling in settings section. (but not thread/task concurrency)

Open

Veeam Backup and Replication (VBR)

Using larger block size can yield up to 3.5x faster performance. We recommend at least 4MB block size.
This is done in the backup job properties → Storage section → Advanced Settings → Storage Tab.

Open

By default, the cloud gateway 7.10.4 uses 50 threads to execute S3 MultiDelete requests, you can improve performance by increasing recursiveDeleteMaxThreads to 250 in /etc/caringo/cloudgateway/gateway.cfg

recursiveDeleteMaxThreads must always be lower than threads and maxConnections

so if you set recursiveDeleteMaxThreads then we recommend also changing:

Example for a cluster of 4 Swarm Storage Nodes

threads = 400

maxConnections = 400

MaxConnectionsPerRoute = (maxConnections / Total Swarm Storage Nodes)

Your Performance Tier has an option to use per-machine backup files, which is the recommended option, this increases the number of concurrent threads VBR uses, but in some scenario’s this can overwhelm your backup repository.

Example: If you setup a backup job to backup 2 VM’s and have this option enabled as well as 8 backup proxy threads then Veeam will use 128 concurrent connections to communicate with the backup repository.

Additional Configurable Parameters on the VBR Side

Backup Proxy Settings

Max Concurrent Tasks per Backup Proxy, by default Veeam recommends this to be set to 2x the number of CPU cores in your VBR server. (Apply the same modifications on the VM backup proxy).

Network Traffic Throttling on the backup proxy

Object Storage Repository Settings

Limit the concurrent tasks against the backup repository if it is overwhelmed.

Handling Multi-VBA Clients

Veeam recommends the use of VBR “managed mode” which provides network traffic rules via their backup proxies. In this mode, all data protection and administration tasks are performed by a backup administrator in Veeam Backup & Replication.

Reference:

If you decide to use the standalone mode then the following simple example HAproxy scenario’s can provide you some level of protection against over-subscribing the object storage target.

Scenario-1: Simple Max Connections ​

You can define maxconn at the backend side,

backend servers​

server s1 192.168.30.10:80 check maxconn 30​

After 30 concurrent connections the rest is queued up.

You can also define how long clients are queued with the following directive:​

timeout queue 10s​

If you timeout you get a 503, which Veeam will retry. ( up to a maximum of 40 mins )

Scenario-2: Sliding Window Option​ (For Burst Traffic Handling)

frontend website​

bind :80​

stick-table type ipv4 size 100k expire 30s store http_req_rate(10s)​

http-request track-sc0 src​

http-request deny deny_status 503 if { sc_http_req_rate(0) gt 20 }​

default_backend servers

Return 503 if the rate > 20 concurrent requests in the last 10s.​

​