cancel
Showing results for 
Search instead for 
Did you mean: 

Backup Exec 2012 slow backing up DAG

Just upgraded to BE2012 and I'm going to backup the DAG, found that it is extremely slow when it is backing up the DAG log file. When I configure it is backup to tape, the rate drops to 1MB/mins after 15 mins. Then I tried to backup to dedup-disk, the rate is ~300MB/mins. There is around 9GB data in my DAG for testing, and it took an hour to finish the backup tp dedup-disk. If it is backup to tape, the last test took round 6 hours for 9GB

I have tried backup files from DAG members, the job rate is normal, 2,xxxMB/min to 3,xxxMB/min. I really don't have any clue about this rediculous low job rate.

6 Replies

...are your DAG servers all

...are your DAG servers all local, or are they spread out across a WAN?

Just found out that it take

Just found out that it take ages updating the catalog~

The backup server and DAG

The backup server and DAG servers are all local.

...have you upgraded to BE

...have you upgraded to BE 2012 SP1a? Please note it is not uninstallable, and the entire application needs to be uninstalled to remove it.

Thanks!

Symantec support keep helping

Symantec support keep helping for a week, yet we couldn't find any conclusion.

I have found one thing interesting from the backup log. The throughput rate of the databases is normall, the rate is around 3000MB/min to 4500MB/min. However, when I look into the exhange log backup throuhput rate, it is only about 200MB/min. I think this is why it slows down the whole backup job.

This is the DAG backup without GRT. I wonder how the figure looks like if I enable this function.

I think this is an

I think this is an architectural problem in BE as opposed to a implementation one in your set-up. We see something very similar. We backup our Exchange 2010 server to a B2D device (SATA-2 RAID-10 local) with GRT and the last backup (~250GB) ran at 1,141MB/min.

As you observe, the main database runs pretty fast but the logs are slow and the catalogs can sometime take ages.

I'm guessing the main database is fast because it's simply a shadow copy directly into the B2D folder. The Exchange backup is a bit of a cop-out IMO as it doesn't even attempt to use the BKF files and compression - it simply puts a copy of the EDB (or whatever) in the folder.

This is why we don't bother using our main deduplication device as there's no reason - it doesn't do any deduplication and the dedupe sub-system isn't as resilient as the B2D sub-system (BE lost with dedupe = all data lost, with B2D you can rebuild by re-backup)

I assume therefore that the logs and catalog steps are not simple file copies and maybe Exchange API calls.

And yes, the GRT backup is even slower.

Cheers, Rob.