VMware Proxy

[Zew]

Hey all,

I'v ebeen running Veeam for a long time as a VM on my cluster in which I backup.

This VM has connections to the NFS datastores, it also has iSCSI connections in which it connects to alternate storage unit to store its backups.

Now using the default proxy has done its job for a long time for the low amount of jobs and processing that is generally required.

I'm also fairly aware of the transports modes used and how they work. i watched a video recently in which someone setups a Windows Server 2012 as a VMware proxy, and showed it was able to run multiple jobs (VMs and their disks at a time) where the deafult VMware Proxy is only able to do one at a time.

Now this video has very vague and simply covered the Veeam GUI and steps within it (not very hard) so all the jazz and jam would have been in showing how the infrastructure was setup in this case.

I happen to have another ESXi host outside of my cluster I use for a test enviro, when i restore to datastores on this host it does [nbd] mode and goes slowly (I can assume cause the Veeam VM does not have direct access to the other hosts datastore) and I'd assume this would be a great host to have my Windows Proxy installed on (another Windows VM of course). however, what would this proxy need to have access to for best performance? vCenter mgmt network, ESXi Hosts Mgmt Network? ESXi hosts iSCSI networks?

[HannesK]

Hello,
in many cases, when the "default proxy" is not fast, then the concurrent tasks are still at the default value of "2".

This screen (properties of each proxy in backup infrastructure). The more cores / tasks the better.

The fastest mode depends on each environment, but in general direct SAN (includes iSCSI & direct NFS & backup from storage snapshots with Ent+ Edition) is fastest, then Hot-Add and NBD slowest. VCenter network is not relevant as no backup data comes from VCenter.

Best regards,
Hannes

[Zew]

So just an update. I went to deploy the VMware Proxy by simply installing windows on my ESXi Test host, and ensuring it was able to communicate to my primary Veeam server via it's default network.
At first I tried to force the source and target proxies in my replication job, it didn't like this and failed, but if I left it at all as automatic, then it properly used the local proxy for the prod system (hotadd) and the remote Vmware Proxy to transfer to the destination datastore which sure enough did a (hotadd) of the virtual disk to that VM and utilized the Veeam transport service.

This made my jobs run about 4x faster.