WAN Accelerator

[nrc]

Hi all,
We have a Headquarter with our datacenter and some subsidiarys with a CD and fileserver.

Right now we are using v.6.5 Std. I now got a testkey for the v7 pro Version and want to test the new WAN acceleration.
I have now copied three backups of the fileservers and cannot see any difference in speed then with v6.5
I expected to see in the data part 'processed 200GB, transfered 25GB' (or something similar). Instead the processed rate is nearly the same than the transfered. Best was 2.1x so far.
Is this normal? Do I have configured something wrong?

Regards
Florian

[veremin]

Hi, Florian,

Do you have WAN accelerators specified at both ends? Do you use WAN Accelerator type of backup copy job, instead of, direct one?

Anyway, you’re likely to see significant traffic savings once the cache in target repository is populated with data blocks. So, it stands to reason either run backup copy job for a while or seed backup copy job in order to fill the target cache and only then take a look at corresponding results.

Thanks.

[nrc]

Hi,
here is our deployment.
VMWare 5.0 Enterprise with attached SAN storage in the HQ.
VMWare 5.0 Essentials with local hard disks in remote Offices.
We want to replicate from the remote Office to the HQ.
Setup a Veeam7 Server with 120GB free HDD space in HQ (also as WAN acc.)
Setup a proxy Server in remote Office with 100GB free HDD space, also as WAN acc.
Made a local backup in remote Office.
Made a backup copy Job with using WAN acc, 100GB.
Source WAN is the remote Office.
Target WAN is the HQ Server.
I can see that the Cache on the HQ site will be filled.
But I can't see that there is this incredible Speed that Gostev have announced.

Regards
Florian

[foggy]

Florian, during first run of the first backup copy job to the given repository there is no cache to use yet, it is just gets populated by the transferred data. You're likely to see transfer improvements on subsequent job runs and other backup copy jobs targeted to the same repository.

[veremin]

But I can't see that there is this incredible Speed that Gostev have announced.

Moreover, please be aware that WAN accelerator isn’t about speed increasing, but rather about traffic saving (how much data is actually being sent though the existing bandwidth). Thanks.

[lobo519]

This contradicts everything I have seen in your marketing material. I just received an email about upgrading to Enterprise Plus :

"Get Backups offsite up to 50x faster with Built-in WAN Acceleration"

[Gostev]

Just wanted to point out here that we provide WAN acceleration only for now. We do not currently offer Ethernet or fiber links acceleration

We've built acceleration for typical WAN links (100 Mbps or slower), on these kind of links you will indeed see up to 50x faster backups due up to 50x reduced size of data transfers. This is what our marketing is talking about. For example, our own IT infrastructure has 6 Mbps dedicated for offsite backups (out of total 10 Mbps), we do offsite backup over Atlantic between our IT sites in Europe and US.

If you have 1 Gb network to offsite location, and it is not already loaded by other traffic, you will likely see Backup Copy working much faster in direct mode vs. through WAN accelerators. However, if that 1Gb pipe is already heavily utilized, or if you don't want to flood it with backup traffic thus impacting other workloads, then you still may want to leverage WAN accelerators to reduce bandwidth consumption by backup activities. Or, say you are paying for traffic used, then still good idea to reduce your bill up to 50x by reducing transfer sizes up to 50x (even though it may work slower than direct operation). So, there are some considerations for using WAN acceleration even for links faster than 100 Mbps.

[tuscani]

I would have to agree that marketing has "overhyped" the WAN Accelerator.. don't get me wrong, its a great addition and appreciated... but to me the main factor that was enticing was supposedly not having to seed jobs where there is a slow connection. If I still have to seed that first time I might was well just do Forward Incremental/Synthetic Fulls. Furthermore, I believe from a previous whiteboard Friday we were told you cannot seed a Backup Copy job.. Is that not true?

[tsightler]

You can absolutely seed a Backup Copy job. Actually this is recommended as the "seed" will be used to initially populate the global cache on the target side. And even without a seed the WAN accelerator can make a tremendous difference in the amount of data transferred during the initial full copy.

[Gostev]

If I still have to seed that first time I might was well just do Forward Incremental/Synthetic Fulls.

You can certainly do that, but this will require at least 10x more bandwidth than with WAN Acceleration. And if your WAN bandwidth is the limiting factor, as it is usually the case, this will translate into 10x slower offsite backup (meaning, you will be able to do offsite backups for 10x less VMs).

Veeam IT did forward incremental with synthetic fulls for years, but this only allowed us to perform offsite backups for 3 most important VMs out of 30 (with our WAN bandwidth and off-hours window).

[tuscani]

Ok thanks Gostev!

[nigejn]

From my experience so far we are seeing approximately 15-20x saving in transferred traffic and is working very well for us as we only have a 4 Mbps upload from the main site. The processing time is slow, it takes 5 - 7 hours to "read" the disks but this is due to slow backup resources but the bandwidth saving is far better than I thought I'd see. The upload data total is now running a 600MB-5 GB a day instead if 10 to 20 GB.

Thanks

Nigel