Backup Copy Job + WAN Accelerator

https://helpcenter.veeam.com/docs/backup/vsphere/wan_hiw.html?ver=120
 

Have a read of this if you haven’t already. Your initial backup will be populating the cache to accelerate subsequent backups.

You’d be best looking at an initial backup seed via a USB3 device or something else similar, to transfer the data between sites if this could be done faster.

Hi,

If you could seed the backup somehow, then you can populate the global cache from the destination backup repository: https://helpcenter.veeam.com/docs/backup/vsphere/wan_population.html?ver=120

Incrementals will be faster subsequently anyway, as they’ll be smaller.

What is the bandwidth available between the sites? I would suggest that until you’ve got this resolved you perform a separate offline backup to take off site such as rotated USB drives or tape backups, so in the event of DR you’ve got an up to date copy of data.

Hi, if it’s 1Gbps are you using WAN accelerator in high bandwidth mode? I would either directly copy or use WAN Accelerator in high bandwidth only in that situation.

Either don’t use wan accelerator or use high bandwidth mode 🙂 high bandwidth mode will try to give you a higher bandwidth throughput relative to your consumed bandwidth and is effective somewhat with this up to 1Gbps.

Personally, unless you have bandwidth constraints, I’d tell it to use direct (no WAN accelerator) and either use QoS or network traffic rules to limit the backup speed during working hours

Okay, my advice would be:

• Cancel the BCJ, change processing mode to direct.

Yes your others will be waiting whilst your full backup takes place, it would’ve been possible to use the synology sharesync backup as a ‘seed’, to avoid another full, if Veeam validated it wasn’t corrupted, if you still have this backup, you could attempt to use it as a seed for your BCJ.

Assuming everything is equal, as in no bottlenecks greater than that of your WAN connectivity, the maths should look like the below:

Lets call the upload 550Mbps, as you’re not likely to hit 100% utilisation all the time.

550Mbps = 68.75MBps

I’m not going to get into the exact of Gigabyte vs Gibibyte so lets just say it’s 7 Terabytes, or 7,000,000MB.

7,000,000 divided by 68.75MBps = 101,818 seconds, or put in minutes: 1696.96 minutes, or 28.28 hours approximately.

So if you don’t have a usable backup in the destination to use as a seed, you can just disable WAN accelerator, throw the data directly to your offsite repository, and within say, lets round this up to <=1.5 Days, you’ll have a full copy there, and can carry on as normal.

This doesn’t factor in exactly any production WAN use, permitted transfer periods etc, but at the high level I believe the point makes sense.

If the backup is gone, don’t worry about setting up sharesync again, I’d always be more worried about data corruption on such a large backup file. Just do the full BCJ without sharesync or wan accelerator 🙂

If you’re worried about your other VMs not processing whilst this large one runs, I’d create a separate BCJ for the big VM so it doesn’t prevent another sync cycle for your smaller VMs during the initial full backup copy 🙂

I just have a question about the BCJ without WAN Accelerator.

Processing rate, speed will be lower, so it will take even more than 6-7 days or?

Thanks for explanation :)

I don't think processing rate will be lower, but I can't definitively confirm because I don't use WAN Accelerators. Depending on your total BCJ job size, your job shouldn't take 6-7 days to run. Just use Michael's formula above, but instead of the 7TB for the 1 VM in the job, use the total job size. This will give you the time it'll take to run the whole job...approximately. Again, since subsequent runs are incremental, it won't take anywhere near as long. 

Without any initial seed

Both sites have NAS Synology that has SMB share. 
Gateways are our Firewalls, we have firewalls on each location. Fortigate to be specific

Concur with Michael. These Gateway Servers he suggests adding will act as Proxies to perform the heavy load & lifting of the BCJ job processing.. I suspect once implemented processing rate will increase. The Helpcenter on BCJ discusses Gateways.