WAN acceleraion vs 2012R2 / 2016 dedupe

[RGijsen]

Hi,
I currently have an onsite HP p2000G3 fc with 16 1TB disks in there for backup. It's mapped as a backup repository on a Windows machine, with 2012R2 deduplication enabled. The dedupe rates are great. For my offsite backup we use some software (and I am thinking of writing my own improved 'version' of that) that relicates the deduped volume the remote datacenter. It replicates the whole volume, but as such that only the changed blocks in the dedupe store are replicated, as well as the reparse points. So basically I really only replicate the changed blocks over the WAN. My WAN link is rather slow, about 25Mbps, but it will soon be upgraded to 150Mbps. My issue remains though that I seem to have so much delta in my backups that even only the changes are way too much for my 25Mbps line. With dedupe and only doing the changed blocks, a full backup should more or less dedupe to the amount of an incremental, still it are the weekly fulls that are killing me.
Upgrading the line might help, but another thing is upgrading to Veeam Enterprise Plus in order to be able to use the WAN Acceleration. I currently have Veeam Standard through the Cloud and Service Providers program, because I still can't justify the price of Enterprise or even Enterprise Plus in our environment. How would Veeam WAN acceleration perform opposed to 2012R2 dedupe, given the fact that both do essentially the same? Would Veeams WAN acceleration be more efficient or should I expect the resulting data over WAN to be about equal?

A sidequestion on that; I've read a lot of product information and if I am correct I would need a WAN accelerator on both sides, the source side being rather small as it only holds the hashes, but the remote site being at least as big as the deduped data as is holds the blocks as well? That would mean another investment to have some blazing fast storage, preferably SSD's on the remote site.

[Gostev]

Hi, the best would be to just try this out with a trial license, as it is next to impossible to guess how our WAN acceleration will compare to "some software" you are using today in terms of bandwidth consumption. But no, you don't need blazing fast storage on the target, and you can set global cache size to anything you want (for exampl, 100 GB will already be good enough in most cases). Thanks!

[RGijsen]

Gostev, thanks for the reply. One question still remains for me, which is what the global cache stores. I see I need 20GB per TB of storage, that's for the hashes, but I guess the optimal size for the global cache would the amount of repetitive blocks? The global cache stores actual data blocks correct?

[Gostev]

Correct.

We usually recommend 10GB per unique operating system used in the environment as there are quickly diminishing returns of going beyond this amount.

By the way, it is not "20GB per TB of storage", see actual requirements and examples here > https://helpcenter.veeam.com/backup/80/ ... izing.html

[poulpreben]

It looks like the page in Help Center was truncated. The updated Best Practices guide for version 9 will probably be published today, and I will make sure to update this thread with the link as soon as it happens.

It is correct that 20 GB per 1 TB of source data is required on the source WAN accelerator for storing the disk digests.

You mention that full backups are what is making your WAN connection struggle. When using Backup Copy Job, everything will be incremental forever. That in itself should give you a 10x improvement, assuming you have a 10% change rate. Additionally, WAN acceleration provides at least 5x savings on the incremental data.

Try entering your numbers in Timothy's awesome calculator here: http://rps.dewin.me/bandwidth. It should give you an idea whether evaluating WAN acceleration is worth your time.

We can optimize a lot, but unfortunately we haven't worked out "Light v2.0" yet

[poulpreben]

Find updated best practices for WAN acceleration here > http://bp.veeam.expert/resource_plannin ... ation.html

[RGijsen]

Thanks for the updates. By the way the topic notification does not work for me; I have enabled that but I don't get any mails, nor are they in our spamfilter.
Having to get the Enterprise plus licenses just for the sake of the WAN acceleration is way beyond either budget and sense. For the $4000+ that costs me + annual fees I can easily upgrade the links or get other solutions. Now I now I am the one asking for help here and of course it's obvious I am 'pushed' to Veeams WAN acceleration. The thing is though that I am still trying to figure out what the theoretical difference would be. Deduplication on disk level is basically the same as WAN acceleration; eliminate duplicate blocks. While I certainly see other advantages in a legit WAN acceleration vs our current setup, I just can't afford that for now as a two-people company.

I'll see if I can get a trial license through our partner and will report later on.

[poulpreben]

I would usually say that if you can simply upgrade your bandwidth and avoid WAN acceleration software in between, go for it! You can use that bandwidth for many other things than just backup traffic, and more bandwidth means increased productivity as well. Most of our WAN acceleration customers do not have such options, which is why we are trying to help out.

However, you should keep in mind that storage based replication means you can end up with corruption for both your onsite and offsite backup repositories. Imagine a crypto attack on your backup repository in the production site, and the volume is replicated to D/R, you have two corrupted copies. When using Backup Copy Jobs, that won't happen, as we will detect CRC errors before transferring the blocks. This goes with and without WAN acceleration though, so it is slightly unrelated. I just wanted to ensure you had evaluated this risk.

[Matts N]

Hello,
I have a minor problem with this simplification:

Deduplication on disk level is basically the same as WAN acceleration; eliminate duplicate blocks.

This statement may be true for replicated storage, but I would argue it is far from true when it comes to Veeam's WAN accelerator. I am under the impression that the Veeam WAN accelerator only accelerates network traffic generated by Veeam, simply because it's not really dealing with network traffic but decides what to send to the network based on what is already stored on the target (or not stored). That means any other network traffic that might flow on the same network interface is excluded from any kind of optimization by Veeam.

It sounds like you are thinking more of a generic WAN accelerator that can handle any traffic on your network link. Maybe that could be a solution too.

// Matts