It seems to be normal. With an average transfer rate of 14MB/s, you have about 8 days to transfer 8.3TB.

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.

For next incremental and full backups it should get faster because we will have full backup already on it?
Its not possible to transfer it via USB3 or similar because we are divided into countries and its not possible to make trip to one site and get files.

Trying to figure the best way.
In case of disaster we will be at least one week outdated from the primary site and that is not good.

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.

The bandwidth on both locations is 1GB connection. 
Before this I was using Synology ShareSync and it was faster but as people already suggested me it was not a good idea. 

I will wait for this to finish and check how the next ones will be. Its really a not ideal situation.
Dont know how to approach this

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.

I didnt enable High bandwidth mode.
This is the site I’m transfering files to.
The source site is a bit faster than this
 

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

But the best option to have backups on both sites would be to use Backup Copy Job?
I tried with synology sharesync, I have 20 Instances with our license so Backup Copy Job seems the best.

But if it will take 6-7 days everytime its not good. Especially that I have one WAN Accelerator for 3 VM’s. 1 is 7TB and other 2 are arround 1.5TB.

Until 7TB is finished others are waiting.

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.

Thank you for this explanation.

So I can try to use it without WAN Accelerator. With that option there is no need to wait for one to be over so that next can start Copying.

I dont have it anymore but I can create the ShareSync again just to have the initial seed.
After that I can start With BackupCopy Jobs. Do I need first to “populate”, “rescan” repository so that Veeam can know that full backup is already there.

For VM’s that have small disks I will continue using WAN Accelerator because its working just fine. Maybe I can enable high bandwith mode for them just to be “quicker” if it can

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

Nice BCJ thread. And really good advice there @MicoolPaul . Just to confirm his suggestion @NemanjaJanicic , I have a BCJ with Gb WAN between the two sites & use Direct mode. There's not really much around the length of time the initial job run taking so long unless you follow Michael's advice on initial seeding. For me, I was ok with the time length for my initial run. Subsequent incremental runs do take significantly less time. If you can be patient through the 1st run you should be fine here on out. 

Cheers! 

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 :)

In your scenario, I expect it to be much faster. Low Bandwidth mode, which it sounds like you were using, is only suitable up to 100Mbps anyway. So I’m expecting much faster throughput.

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. 

I started it from the scratch with Direct mode.
This is the statistics for now

Without any initial seed

Hi,

It says your botleneck is the target. So can I ask, how are you accessing this storage? Is it an SMB share, or NFS share, or is the storage attached to a server?

If it’s an SMB or NFS share, where’s the “gateway server” is it within the destination site?

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

Hi, I mean gateway servers in a different sense, when you create an SMB share, you choose a “gateway server” to communicate to it.

Check the source and destination SMB Shares as to what their gateway servers are.

I suspect your gateway server is your VBR server or another server located within the source site, so you’ve got a suboptimal path for reading/writing blocks on the SMB share. If so, you can deploy the gateway server role to near enough any server in the backup copy site. This will speed things up.

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. 

I understand now what you mean.

Yes, on the site where the files needs to be copied gateway server is VBR which is located on another site.

So to sum it up I need to chose a server which is located within the site to be gateway server?
I will configure it like that and after start start the job again

Your data flow is currently as follows then:

Source Synology NAS → Source Gateway Server (Likely VBR server) → Destination Gateway Server (Also VBR server so just loopback traffic) → Destination Synology NAS.

Which looks simple enough, but the issue occurs with IO requests, as the VBR server is having to manipulate a large backup file on the destination Synology NAS with reads and writes both traversing the WAN.

If you swap it to:

Source Synology NAS → Source Gateway Server (Likely VBR Server) → Destination Gateway Server (within Destination site) → Destination Synology NAS.

Then the WAN is only being used to shift blocks from source to destination gateway servers that need to be committed, and the gateway server is handling the IO read/writes to Synology at LAN speed.

Thank you really much.
This cleared my mind. Its already looking better.