Direct transfer VS Wan accelerator transfer for BCJ

[lmbutault]

hello,
I have done some testing on a customer environment and get results I did not expect.
Customer has a 50 Mbps VPN link between two countries (about 1 000 KM distance / about 35 ms ping time) and is using Veeam Wan acceleration on SSD drives
We are doing BCJ of around 50 VMs (10 TB storage) between both sites.
We have noticed a huge improvement on disabling Wan acceleration coming back to direct transfer (*5 speed).
Main reason we have noticed is that with wan acceleration on, every VM's Disk is made sequentially as with direct transfer they are done in parallel up to the repository limit.
Anything we could have missed?

[csydas]

Veeam's WAN accelerator doesn't do task concurrently as far as I know, so that's why you're seeing this difference.

You can either spin up more source WAN Accelerators, or just do it direct. Your connection should be fast enough to support direct, though you may need to seed the backup copy.

[skrause]

Make sure your WAN accelerators are sized correctly for the amount of data you are sending, as well as how many different OSes are in the VMs being sent.

You may be running into an issue where you don't have enough/fast enough cache space on the WAN accelerator.

https://helpcenter.veeam.com/docs/backu ... tml?ver=95

[DGrinev]

Hi,

My 2 cents: You should keep in mind that the WAN Accelerator significantly reduces the amount of data sent, thus can save you money for the traffic. Thanks!

[lmbutault]

thanks for your answers,

my goal is to have the best SLA for the BCJ, I mean by this reducing the time to make the BCJ, not reducing the amount of data sent.
I prefer to make a direct BCJ running in the night backup windows and using full bandwith than dealing with wan accelerator to reduce amount of data but having it still running during production hours.

WAN accelerator was designed confortably, with 1TB dedicated SSD drive on each side.