Backup Exec 2012 Slow B2d Performance Over WAN

[reighnman]

I had a similar issue when running BE 2010 (https://www-secure.symantec.com/connect/forums/backup-exec-2010-r2-slow-performance-over-wan), which was resolved by a WAN optimizer, unfortunatley even at full speed we didn't have the bandwidth to make our window so the project was scrapped0.  Fast foward to today, we've since upgraded to BE 2012 and are looking to reimplement the off-site DR now that we've upgraded the WAN link between our two primary sites (Chicago/Houston) to 100mb.

This time, even using a WAN optimizer, I get extremely crawling speeds when trying to do a backup with B2D (via UNC path to off-site host) or RMAL (via NDMP to off-site RMAL host with virutal tape drive).  I'm talking about 100MB/min, or about 5-10mbps when monitoring the WAN link.  No performance changes with or without the WAN optimizer in place.

I've also tried to use the B2D test tool, which does some backup simulations with 4GB test data, but it crawls even slower.

NTBackup, SCP, SFTP, Windows File Transfer between the same source/destination server are all able to fill the pipe @ about 80-90mbps, but not BE.  There is little to be done in terms of customization with BE so I'm not sure what I can try.

Any ideas?

[reighnman]

On a side note, running the same backup test (duplicating a backup set) to a unc path on the local 1gb LAN get's around 800mbps.

[reighnman]

This appears to only happen on duplicate jobs.  Performing a a test 4GB backup straight to NDMP/RMAL agent from disk I can fill that WAN link.  But when I do the same test data do local disk, then duplicate the backup set to NDMP/RMAL I get minimal speeds.

Straight backup to NDMP device:

--- Transport STATISTICS ---
Remote       SendRate Mbits/s  R/Trip  
HyperIP      Target-Current    msecs   
tx1             90  84.872      31    


Duplicate Set to NDMP device:

--- Transport STATISTICS ---
Remote       SendRate Mbits/s  R/Trip 
HyperIP      Target-Current    msecs   
tx1             90  13.056      31   

[teiva-boy]

BackupExec has NEVER been supported to do this type of config.  Not to say that it's not possible.  Just that Symantec has never tested and will never bless it (Most likely)

Typically, BackupExec hates dropped packets and latency.  One dropped packet can bring down an entire job.  A high latency link can cause issues with BE doing CRC checks and verify's on its writes.

You'll have better luck with aan OST device, or two BE servers with dedupe licensed doing an "Optimized Duplication."  At the very least it'll be a supported config.

At the very least, have you tried multiple smaller jobs?  That run concurrently?