Backup Copy to Branch Office VPN

[bunger]

We have been running Veeam B&R for a couple of years and have just implemented Backup Copy to a Branch Office via a VPN link. The link is over a broadband connection and the main site's upload speed is 7MBs.

We are backing up 6 servers using Reverse Incremental. If we were to perform a full backup of all servers, it would consume roughly 3TB ( give or take a little ).

Prior to this new configuration, we had been using an appliance by Datto to backup locally and to the cloud. We were backing up the same servers with the same amount of data and the cloud backups were able to complete during the over-night hours.

I have enabled WAN accelerators between the main and the BO offices. I also seeded the initial backup over the weekend to avoid having to push 3TB over that connection. The initial seed/mapping was successful over the weekend.

I am not finding that my nightly backups and subsequent copy jobs are taking far longer than anticipated. The backup job is taking roughly 2.5 hours to complete, then the copy job kicks off ( roughly around 8:30pm EST ). By 7AM the next morning, I am only 44% complete in the copy job, which clearly isn't going to work.

Given that the Datto solution could provide backups to the cloud overnight, what areas do I need to tune/tweak with my existing configuration to be able to push these copies offsite overnight?

Thanks in advance!

[foggy]

Bill, what are the bottleneck stats for the backup copy job?

[bunger]

Statistics on the Backup Copy Job show the bottleneck as "Target WAN"

[foggy]

That means you need faster disks for the global cache. WAN acceleration is all about trading bandwidth for disk I/O and target WAN accelerator's cache speed is the primary bottleneck in your case.

Is the target WAN accelerator installed on the same server as the repository? If yes, is the global cache located on a separate disk from the repository itself? Have you checked the I/O latency?

[bunger]

The WAN accelerator is installed on the same servers as the repository and the cache is on the same disk as the repository itself.

Both the local and remote servers are HP DL360 servers, 96GB RAM, with internal 15K SAS drives for the OS.

Each server has a SAS-attached HP MSA60 populated with 7200rpm, 6GB SATA drives.

The MAS60 houses the repository on each server and also the cache.

[bunger]

Also... the cache size for each location is 100MB.

[foggy]

If getting faster disks is not an option, I'd put the cache on a separate disk at least, to see whether this helps.

[bunger]

I just searched on how to move the Cache and can't find much.

Do I just change the location on the WAN Accelerator definitions and then copy from the old location to the new location?

[foggy]

I'd first copy the cache folder to the new location and then re-point WAN accelerator to it.

[bunger]

I just performed the following steps:

copied d:\VeeamWAN to c:\VeeamWAN
Launched Veeam B&R > Backup Infrastructure > WAN Accelerators and changed path for Cache from d:\VeeamWAN to c:\VeeamWAN
Although previous step restarted the WAN service, I also restarted a second time

Are there any other settings I should be tuning? Would incremental create smaller files to push across or anything else that I am missing?

[foggy]

These steps should be sufficient for changing the global cache location. Of course incremental job runs transfer just changes since previous run, I thought that we already were talking about incremental runs, since in OP you've mentioned that "initial seed/mapping was successful over the weekend".

[bunger]

You are correct. I did do the initial seed and am now running reverse incremental.

What I wasn't sure about is whether "traditional" incremental shows any advantages for backup copy over WAN Accelerators vs Reverse Incremental...

[foggy]

Ah, got it. Forward incremental is a better source for backup copy in terms of performance.

[DaveWatkins]

Also... the cache size for each location is 100MB.

Is that a typo? Shouldn't it be orders of magnitude larger?

[foggy]

Bill meant 100 GB I suppose.