Copy Job - Merge - WAN traffic

[Berniebgf]

Hello,

Can someone confirm the following for me, this is what I am hearing from support.

If you do not have WAN acceleration enabled for your copy job (offsite WAN link (secondary location), "merging" data will traverse the WAN link (again!) if your Veeam Management Server is at the primary location

Sounds ridicules that it will transfer the data again across the WAN link via the Veeam management server when both the Full and incremental data is already there ready to be merged..

Someone say it isn't true@!

Bernie.

[alanbolte]

The only situation in which this would be true is if your repository is specified as a CIFS/SMB share and the automatic gateway selection logic has somehow chosen your Veeam Backup server instead of a managed Windows server at the offsite location.

[Berniebgf]

Here is the setup

Prod: Veeam Management / Proxy on Windows Host with local disk repository (SAN Storage)
DR: Veeam Proxy on Windows Host with local disk repository (SAN storage)

Job has been running for 70+ hours.. and still merging.

Veeam Support are saying it's the WAN link causing the Merge Process to be slow, we are seeing no Disk IO and very little network load.

Bernie

[alanbolte]

Per forum rules, please post your case ID.

[Berniebgf]

Case # 00746419

[foggy]

What are the bottleneck stats for this job?

[Berniebgf]

bottleneck stat from memory (at home now) was 99% network.
However looking at the stat's we do not think these update (therefore not valid) during the merge function.
No traffic is shown scrolling across the "throughput chart" in the job during the merge process, only when processing the VM's on the Copy Job. Would that be true?

It is always Network as the WAN link is the biggest limit.

regards

Bernard

[foggy]

Correct, bottleneck stats are generated on completion of the data transfer period. If your target storage is added to Veeam B&R as a Windows type repository, then the synthetic activity is performed locally by the data mover agent installed on the repository server, WAN is not involved in this case. We have an adjacent thread discussing similar issues, please review and continue investigating with support.