Video Screencast Help

Backup Exec 2010 R2 Slow Performance over WAN

Created: 11 Apr 2011 • Updated: 12 Apr 2011 | 7 comments
This issue has been solved. See solution.

Here is the situation...

Backup Exec 2010 R2 (fully patched/updated on Win 2008 R2 SP1) runs local backups of our servers nightly followed by a duplicate set to tape, everything runs great.  On Saturdays, I try to do an off-site backup to one of our remote sites via 50mb fiber links.

For these remote backups, I've tried using a B2D folder mapped to a UNC path (\\remoteserver\share), and I also tried RMAL/ndmp (remote media agent for linux) using a virtual disk library, both with the same result.  The problem is the backup (via either device) is always limited to about 8-11mb/sec (60-80MB/min), even though 50mb is available.

I've tested the throughput between multiple test sites varius ways, I can always get 40-50mb.  The kicker is, while a job is running off-site at 60-80MB/min, I can start the same job 3 more times to fill up the remainder of the pipe, but a single job will not use up the bandwidth available.

So I'm stumped and symantec keeps closing my cases blaming enviornmental issues, any ideas?

 

Comments 7 CommentsJump to latest comment

reighnman's picture

Been digging around the kb all morning and still can't find any issues of this sort.  Doubled checked the performance tuning documents, double checked duplex, no compression, no encryption, no anti-virus, etc..

I also attached a picture of the interface usage, where you can see the initial job starts and hangs a 10mb/sec, followed by several copies of the same job (all going at about 10mb/sec).

bw.png
teiva-boy's picture

This is pretty normal in my experience.  Due to the nature of TCP and backup streams, the only way to maximize throughput is with multiple concurrent streams OR the use of a WAN accelerator between WAN endpoints.  WAN Accelerators from the likes of SilverPeak, Riverbed etc all maximize TCP connections and optimize to use all available bandwidth.  

Unoptimized TCP just sucks, it would be great if you could use UDP.  Of course, backups storing over a WAN link via CIFS is just plain slow too with it's own set of inefficiencies.

There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) http://mysupport.symantec.com "We backup data to restore, we don't backup data just to back it up."

SOLUTION
reighnman's picture

Do you know of any accelerators that offer demo periods so I could test that type of solution?  I've always been wary of optimizers/accelerators.

If it does turn out to be an issue with tcp in general, you'd think tier 2 support would have been able to tell me.

Colin Weaver's picture

You might want to look at DeDuplication and the "Optimized Duplication" feature that allows you to move DeDuplicated datat between media servers without re-hydrating the data. I belive you need a CASO configuration with DeDup to use this ability and there are some limitations on the types of data that are still rehydrated against the types of data that stay in DeDuplicated form for the data transfer.

reighnman's picture

We have dedup, but I'd rather first identify the raw performance issue before looking at compression or dedup.

reighnman's picture

Looks like you were right, put some HyperIP wan accelerators in place to test and get 50mb raw throughput to RMAL/ndmp no problem. 

 

Thanks!

teiva-boy's picture

Just a personal preference, I like SIlverPeak, and had been a customer for a number of years and one of their sucess stories.  What I like about them is their packet re-assembly for dropped packets, and ability to accelerate SSL traffic (I believe that was the specific feature?)  It's also available now as a VM image.

Riverbed is the market leader for this stuff.

HyperIP, I've never heard of but I'm sure it's a solid product

There is an online portal, save yourself the long hold times. Create ticket online, then call in with ticket # in hand :-) http://mysupport.symantec.com "We backup data to restore, we don't backup data just to back it up."