Have I moved backwards in offsite data?

[seapro220]

Hello all.
I wanted to post this to see if anyone else was experiencing the same think I've noticed, and if you've found any work-arounds that perhaps I'm missing ..

Before V7 -

Ran 6.5 with latest patches.
I have 5 jobs for my servers, all are running reverse-incrementals with 'rollups' into their weekend vbk file.
"constant" running robocopy jobs to 'sync' all my non-vbk files over everyday via my 10-Meg VPN connection to a remote site.
Every Sunday I have a 'copy' job which transfers my vbk files to a external 4Tb drive which I manually transport offsite and upload to the NAS over there.

Now - running V7.

I recreated the same 5 jobs.
carved out space on my NAS and put all the 'newer' named files there.
stopped the V6.5 jobs and all the robocopy processes.
created some 'shaped' proxy rules so that I was limiting my business-hours "backup traffic" to only 6MB and wide-open after-hours.

I was excited that perhaps the WAN accelloration process might handle all the "dedup, incremental changes, and even possibly the vbk'" files for me. I'd thought this would be a reduction in "steps" for me by removing the Sunday/Monday tasks. I thought that perhaps the shaping of the proxy boxes with "wide-open" after hours might be able to massivly push out all the data and hopefully get me 'caught' back up by tuesday am at the latest.

I haven't found this to be true. Not only haven't I been able to push out all of my vrb files to my remote site, but I dont have "full vbk" files offsite. I'd thought perhaps I didn't have enough 'cache' space, or perhaps not enough proxy boxes - but alas, nothing seems to be working. As of this time, I have backed up 943Gb at my local site (where my initial backups are done) and only transferred 497Gb accross the wire. How dissapointing to say the least, as I now have to figure out how to reverse-engineer this process. I'm going to somehow figure out how to stop the wan accelerators and transfer (at least) the vbk files manually again. Whenever I make this change, I dont know how the 'cache' process will react and work.

Please - If there is someone out there who has figured this out and how it actually might work, please let me know. I have 4 proxy servers configured, and 3 WAN accelerators - along with the same 10meg circuit.

thanks -

[foggy]

Mark, could you please share your backup copy jobs settings as well as the bottleneck stats for them? Have you enabled WAN accelerated mode for them?

[seapro220]

sure - Here's an example of one of the jobs. The others are similiarly configured ..

Backup job -

back up of data daily, with incremental job - full on friday night. all 'writes' are to a local NAS at the corp office.

backup-copy job - adservers
job name - ad servers backup.
object to process - name - adbox-copy. type - backup job - size 58.1Gb
target - remote repository name (v7rbackups) - 7 restore points. nothing selected along the "keep the following restore points...."
data transfer - through built-in wan accelerators. source, local veeam backup server, remote or target accelerator - remote ip address of a virtual machine.
schedule - any time (continuaously)

other misc info -
veeam backup servers - 8 concurrent tasks, 4 procs and 12 gig's of ram.
2 remote proxy boxes and ip's configured for my wan accelerators - 4 proc's each and 8 gig's of ram.

It would appear, based off of some alarm-warnings that I'm getting that this is happening, during the 'copy' process.

all data is copied from the local to the remote site and kept in a 'proxy cache' state. the proxy cache is compared between the 2 different boxes, 1 local and the other remote, then what ever changes are 'noticed' those changes are written to the remote site so that the data is current, and the same. I'm used to 'writing' the changes and not doing any type of proxy-cache process and perhaps this is why everything is taking soooo lllloooonnnngggg !!!.

[foggy]

You haven't specified the processing rate and bottleneck stats for the backup copy job. Basically, backup copy not just copies files but rather synthetically creates restore points in remote location from the changed blocks extracted from the source storage and, since WAN accelerators are effectively trading disk I/O for WAN bandwidth savings, disk I/O performance on the target repository is in most cases the primary bottleneck in the WAN accelerator process.

[seapro220]

If you are referring to processing rate - then I have 5 streams configured on 6 wan accelerators, and if you are referring to the bottlenect stats - then I am unsure, unles you are referring to the 'time of day' in which I can configure my bandwidth for the jobs. Other than that, I don't know what you are referring to - hense the questions here as to what I might have missed, or misconfigured.

[foggy]

Right-click the job and select Statistics. You will find a lot of useful information in the displayed window.

[Vitaliy S.]

I haven't found this to be true. Not only haven't I been able to push out all of my vrb files to my remote site, but I dont have "full vbk" files offsite

Backup copy jobs is not about moving backup files, it is about copying VM data blocks and creating VBK/VIB files on the target repository. Just to make sure we are on the same page - do you see any files created in the target repository?

[Gostev]

OK, I've honestly read the original post 3-4 times, and still could not understand what is the issue. I am sorry if I missed something, but almost like some words describing the actual issue are missing from the post. Is the issue that full backup of 1TB of data over 10 Mpbs (throttled to 6 Mpbs) link taking too long?

I don't think pursuing bottleneck investigation is the right direction here, because one should be able to saturate 6/10 Mbps link with pretty much any imaginable modern hardware.

So, first things first - what is the issue?

And a few other questions:

1. Why do you use more than 2 WAN accelerators (one at source, and one at target site), when you only have 10 Mbps pipe? Having multiple WAN accelerators will NOT help, until we are talking about 100 Mpbs+ WAN links. And, this will most definitely increase traffic usage significantly, especially during initial cold sync with empty WAN accelerators caches and performed without backup seeding.

2. Some screenshots of Backup Copy jobs real-time statistics would be helpful.