...
The best practices for using DataCore Swarm object storage as the capacity tier in a Veeam Backup and Replication Scale-out Backup Repository include sizing and configuration guidelines and as well as operational tips for optimizing the backup and recovery processes. These practices may be updated periodically as new lessons are learned.
...
The smaller the block size, the more calls are needed to the object storage to upload the data. DataCore recommends to use “Local Target (large blocks)”. This is equal to a 4MB (=2MB after compression) object size. Performance Tier storage requirements depend on this setting, too.
Consult with Veeam or your partner before setting this.
...
Each SOBR offload task will use up to 64 connections to the capacity tier. This is defined by S3ConcurrentTaskLimit in the Windows registry settings. (HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\S3ConcurrentTaskLimit , requires a reboot to apply).
We recommend approx. 2,000 connections (approximately) for onOn-prem Premise object storage.
The default value of 64 (decimal) is applied to every worker process, meaning that the “SOBR Offloading” job overall may be using hundreds or thousands of concurrent connections, resulting in sub-optimal performance.
The performance will depend on the Veeam setup in the environment. If you have a single repository with 8 concurrent tasks , and the above setting is left standard, you may have the ability to overpower the object store. For example: 8 x 64 connections, which may result in high CPU usage.
...
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).
For more info information, see https://helpcenter.veeam.com/docs/backup/vsphere/limiting_tasks.html?ver=120
...
By default, the cloud gateway 7.10.4 uses 50 threads to execute S3 MultiDelete requests, you can improve performance by increasing MaxRecursiveDeleteThreads recursiveDeleteMaxThreads to 250 in /etc/caringo/cloudgateway/gateway.cfgMaxRecursiveDeleteThreads
| Note |
|---|
Warning recursiveDeleteMaxThreads can overwhelm your Elasticsearch cluster if its not sized for the workload, in some situations you may have to reduce this configuration to get less CPU load on Elasticsearch. |
recursiveDeleteMaxThreads must always be lower than threads and maxConnections
so if you set MaxRecursiveDeleteThreads recursiveDeleteMaxThreads then we recommend also changing:
...
| Note |
|---|
WarningIf you add more Gateways, be aware that all the parameters above need to be divided by the number of gateways you have in your environment. |
Veeam v12.3 auto-provisioning of buckets feature
Veeam v12.3 introduced the concept of auto-provisioning of buckets in a single backup repository based on a configurable total objects threshold.
We do not recommend enabling this feature as it will not yield any performance improvements under Swarm. Swarm Per Domain Indexing focuses on performance improvements at the domain level not the bucket level.
Final Remarks
For additional technical details, see Veeam V12 Guidelines.
...