This post is also available in: Italian

If you are using Veeam Backup & Replication with a VMware vSAN datastore you are probably following the Veeam KB 2273 (Configuration for VMware VSAN). But this guide is only limit to recommend the hot-add transport mode.

So you are going to create several Veeam proxies because Veeam Backup & Replication chooses the most appropriate backup proxy to reduce the backup traffic on the VSAN cluster network. Maybe also one per host.

But if you run your backup jobs you will notice that backup are “slow” and always limited by the source.

If you are looking for the VMs you probably may notice that several VMs are waiting and the reason could be that they are waiting for a proxy, for the repository… or for the datastore.

In the last case you will notice a message like this:

Resouce not ready: Active snapshosts limit reached for datastore

What does it mean?

Veeam has added the ability to limit the maximum amount of active VM snapshots per datastore to prevent VM snapshot issues and also to reduce the probability that the datastore will be overfilled with snapshot deltas. The default value of 4 active snapshots can be controlled with a Windows registry key on the backup server as described in this community post.

But on vSAN this limit makes not much sense, considering that ALL VMs are on a single datastore: you are limiting the overall operations of your backup jobs!

The registry key is MaxSnapshotsPerDatastore (REG_DWORD) and it’s located in:

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication

Note that the value type for this key is a DWORD (32 bit) and you can write the value in hexadecimal or decimal:

• If you enter 12 and select decimal, the value stored will be 12 decimal (DWORD 0x0000000c)
• If you enter 12 and select hex, the value stored will be 18 decimal (DWORD 0x00000012)

You need to restart the Veeam Backup Service in order to active this changes.

If you increase this value you can reduce the amount of time consumed by your jobs, especially for incremental backup where most of the time is wasted to get the VM, prepare for hot-add… if you also add delay because the queue can manage only 4 VMs per time… then the overall time will increase.

Which value it’s optimal? It really depends on your environment, the number of proxies, the number of repositories, the limits on each of them… In my case a value between 8 and 12 was the best to achieve the minim time for incremental jobs.

Note that storage snapshots (in VMware vSphere environments) have different options and limits. In this case, it’s also possible to manage the limit from the GUI.

To limit the number of storage snapshots, you must enable the Limit processed VM count per storage snapshot to <N> option and specify the number of VMs per snapshot in the job settings.

But for VMware vSAN there isn’t a native storage snapshots option (snapshot remains VMware’s based snapshots, with some differences due to the vSAN filesystem). In this case, the only options to speed up your backup is to use the registry key.

Andrea Mauro

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.