Hi @lgh and welcome to the community.

Normally i would prefer that you have a minimum of 1 proxy per site. Depends on your amount of VMs/Data you want to backup, more proxies or resources for these are required.

If you have only your VBR as a proxy, a lot of traffic traverse between your VBR site and the site where your VMs are placed…

Proxies can have different transfer modes → Transport Modes - User Guide for VMware vSphere (veeam.com)

Just be be clear: am i right, that on your sites where your VMs are placed, there is no local repository - so all your backup data will be transfered to your main site (where also the VBR is located)?

I would recommend also, to have a minimum of one local repository on each site - for the primary backup target. In a backup scenario you wouldn’t have a bottleneck by connection between your sites, the backup windows will decrease (and so also the time, where a VM has an active snapshot). I case of a restore (or an instant recovery), you would restore the data from the affected site. But it’s also recommended, that you have a secondary copy offsite - here you could use a backup copy job - this wouldn’t effect your vSphere environment a second time.

Cheers, Markus

Markus is right with what he has said.  If you want a good understanding of Proxies as well as other components you can check the best practice website.  Here is the proxy section - https://bp.veeam.com/vbr/2_Design_Structures/D_Veeam_Components/D_backup_proxies/vmware_proxies.html

Hi @lgh -

Markus touched on why Proxies can help and some on Transport Modes. As he shared, you really need a Proxy at each site if you’re sending data from a given site to another. The Mode used, as well as Proxy location, physical network cables, & bandwidth is what mainly determines Backup speed (there are other factors, but those are the main drivers). I assume then, kinda as you state, you’re simply wanting better Backup times? What are you getting now? How many MB/s?

Do you know what Transport Mode is currently used? You can determine this in a couple of ways → look at the the configured Proxy for a given Job; go into the Proxy’s Properties; see what Transport Mode you have configured. If it’s set to Automatic, then Veeam determines the Mode based on your Job and VBR configs. If this is the case, to determine what’s used, go into a Backup Job (double-click it) and look at the Job History Task list on the right. Find what Proxy the Job (Veeam) decided to use and see what is shown in brackets. It will either say esan] , ]hotadd] , or cnbd] . If you’re using nbd], that is Network Mode and the least performant of the 3. There’s actually a 4th Mode, and that is Backup from Storage Snapshots, which is about as performant as DirectSAN. I assume you’re not using that one. The 2nd best, arguably, is Virtual Appliance or hotadd. I use this for some of my Jobs and I can actually get up to 3+GB/s at times! This is only used if you use VMs as Proxies. Since you shared you have 10Gb NICs, I assume you use Physical boxes for Proxies only?

So with those assumptions, you should follow the Guide on how to configure DirectSAN or DirectNFS.
https://helpcenter.veeam.com/docs/backup/vsphere/direct_san_access.html?ver=120
and
https://www.veeam.com/kb1446

There’s other articles out there as well. I actually posted one on how to configure Linux Proxies if you’re interested in that route at some point.

Basically, you would need to configure access to your source storage (i.e. the datastores VMs reside) for the Proxy(ies) used for a given Job. The access required is dependent upon the storage used. For my environment, I would need to assign the iSCSI IQN (I use iSCSI, not FC) to the source datastore Volume on my Nimble and give the Proxy IQN “Volume” level access (not Volume and Snapshot, and not just Snapshot). This allows the Proxy to directly access your source VM storage and then write directly to your Repo.
https://helpcenter.veeam.com/docs/backup/vsphere/direc_san_access_backup.html?ver=120

To also speed up your Jobs, you should configure your 10Gb NICs properly. Connect a proper cable and, if possible, isolate your storage traffic from mgmt traffic.

Hope that helps. Let us know if you have further questions.

I’ll also note that if my VBR server is not virtual on the VMware environment, and is a physical server or other, I like to place one proxy server per host.  It’s not necessary, and I’ve moved over the using linux proxies because they’re lightweight and there’s no licensing required vs the Microsoft tax for a Windows VM.  But it’s great because it then has direct access to the VMDK’s using the hotadd transport mode.  As Shane mentioned above, hotadd is preferred over network (NBD) because you’re then not subjected to throttling by VMware if you were transporting through the management vmkernel NIC.  In a small environment, that may not be a big deal, but as you grow or if you have higher IO, it’s generally better to utilize hotadd.  That said, direct SAN access is fantastic as well.  Most of my new environments I build have a physical VBR server with local storate and have direct SAN access via either ISCSI to SAS/DAS to the storage array.  It’s makes for exceedingly fast backups overall, and while not necessary, are great to have and takes the load off of the hosts.

The fastest option will be a physical proxy using direct SAN at each site. Depending on production storage, using storage snapshots really takes the load off of the storage as well.

If you are using Virtual Proxies, 1 per cluster at a minimum, but you can go as far as one per host depending on your needs and works with hotadd. NBD can end up being much slower.

If your VMware management is on 1Gb ports, check for this as it will be very slow compared to using the 10Gb connections.