WAN Accelerator without SSD

[eiskra]

We will run large Backup Copy jobs (2 gb of backup files) from our primary DC to an offsite location; there is a 100Mb pipe between the sites. Seeding is not currently an option.

We also can't add SSD storage at the moment for WAN acceleration purposes, but we have VM's and conventional storage space available. (SAN space in the DC, local drives in the offsite.)

Since the offsite location is also a regular office for the firm, we need to throttle the bandwidth during much of the day, so we are, in fact, limited on bandwidth.

The question: is setting up WAN acceleration at both ends still worth it, given that we will only be able to use (relatively) slow storage for the caches?

My guess is that the answer is yes - the data transfer savings should be just as big with slow cache as with fast cache, but the transfers will not be calculated as quickly, and so the system will be less capable of saturating the pipe. Given our need to throttle the pipe during most hours, this suggests there's no loss in overall performance due to the slower cache.

Thoughts?

[andersonts]

Hi can you verify that your backup copy is 2GB versus 2TB? Also can you relate how much bandwidth you will have available to use during the production hours? Your assumptions about the disk cache are generally accurate faster disk = better cache performance and faster calculations. Also important to note is that the cache would be built gradually so your first run will still be a full copy...that said you don't have to copy every VM initially you could start with a few then add a couple at a time until you have all of them.

[eiskra]

You are correct - I meant to say 2TB, not GB.

We throttle the daytime bandwidth for backups down to 40 Mbps during production (which is more than 12 hours), and 80 Mbps during off-hours.

Adding servers gradually is not much of an options - the jobs in question are just two servers; one is a master replica of all file shares, and the other is an Exchange servers with replicas of all mail stores.

Do you agree with the idea that, in our environment, WAN acceleration is still worth doing, and will still provide a benefit, even though it will have "slow" cache?

[Gostev]

We have a deployment internally that does not use SSD, it's not fast but this does not matter (we are not in a hurry in the first place - as long as transfer completes in less than 24 hours, we don't care how much it takes). What matter is that it saves us significant amount of bandwidth for other activities.

[andersonts]

So is the daily change 2TB or that is the size of the "full" backup is 2TB (easy to check total size of .vbk versus the incremental .vib/.vrb files). You also mention that seeding isn't an option correct?

[eiskra]

Andersonts - yes, the full backups of the servers in question amount to 2TB, roughly 1 TB each. Daily delta runs from 50 to 115 GB.

Gostev - thanks, that was my thinking. The catch is that we may be better off just continuing what we currently do - one backup job to local, one backup job to remote.

[Gostev]

This might be an option depending on the available bandwidth and a few other things. This certainly was not an option for us due to lack of bandwidth and impact from VM snapshot commit. Remember that with remote backups, VM snapshots stay open for hours and grow very large, resulting in snapshot commit taking very long time impacting production workload.

Basically, there is no reason not to use Backup Copy job instead (even without WAN acceleration), as this solves the latter issue.

[andersonts]

So I am taking the 40mbs and the 115GB using just a file transfer calculator assuming 10% overhead and based on that you should have the data transferred w/o the WAN accelerator in less than 8 hours. I assume that would be acceptable? You issue with not being able to seed is something that the WAN accelerator should help with but it's impossible to know how much. Are you able to open the link up from Friday night to early Monday morning? Assuming yes then you could do a VM each weekend for 2 weekends and have the data there since you can't seed. Another option might be to use Veeam ZIP on the machines and see how much it compresses the data...I have seen it do 10:1 fairly often. If that worked then you would end up with significantly smaller files which could be used as seed data. Hopefully this gives you a few reasonable options.