Veeam NTX remote proxy for remote repo?

[PAP400]

In HQ I setup a brand new nutanix cluster (70 VM, 70 TB) with its Prism central on it.
I have a VBR 12.x server (used for some other vSphere environment too) and deployed a Veeam NTX proxy through Prism Central.
Backups are primarily stored on a dedupe appliance located at headquarters.

Then I setup other 2 NTX clusters on different branches, both registered on the same Prism Central.
One site is linked with a 1Gb/s “dark fiber” (so there is no problem) but the other one communicates using a poor MPLS link.
For the latter case, because the connection is slow, I thought to copy data using its local repo (and not the dedupe appliance set in the HQ), but data come across HQ, notwithstanding worker is on the branch cluster (and same vLan).

Can I solve the problem deleting the PC-registered Veeam proxy and using 1 proxy for each NTX cluster instead?
I’m asking because It seems that even a remote repo cannot have a NTX proxy as gateway: am I wrong?

Thanks for your advices.

PAP400

[ronnmartin61]

Are you saying you have a Veeam backup repository defined at the remote locations? If so the Veeam AHV worker VMs in the remote clusters should simply write directly to the local Veeam repository without hair-pinning traffic through your main location. When VBR sets up the backup processing workflow it's simply passing along the repository IP to the worker which should then make a direct connection to the repository.

[PAP400]

Hello Martin,

thank you your reply.

>> Are you saying you have a Veeam backup repository defined at the remote locations
Yes: a NAS set in the same site of ntx cluster and all in the same vLan (ntx management, Veeam Worker and VMs)

>> If so the Veeam AHV worker VMs in the remote clusters should simply write directly to the local Veeam repository without hair-pinning traffic through your main location
What you're describing is exactly what I expected to happen, but, unfortunately, I noticed that the data flow originates from the worker, which forwards the data to the Veeam server, which in turn writes the data to the remote repository: this means that the backup data blocks travel across the WAN twice!

In any case, I think I have resolved the issue by creating a vSphere (!) Veeam Proxy (remote) and designating it as the explicit gateway for the remote repository, but I'm not so confident of this workaround: What do you think about it?

TIA

PAP400

[ronnmartin61]

Got it! Yes we'd need an explicit NAS repo gateway server of some sort to keep the traffic local.

On this note we've had some requests for enhancing the worker's available capabilities to include built-in gateway services (NAS, S3). I'm assuming you'd endorse this enhancement?