09-24-2012 09:22 PM
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.
09-24-2012 11:29 PM
...are your DAG servers all local, or are they spread out across a WAN?
09-24-2012 11:30 PM
Just found out that it take ages updating the catalog~
09-24-2012 11:36 PM
The backup server and DAG servers are all local.
09-25-2012 12:51 AM
...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!
10-03-2012 07:17 PM
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.
10-04-2012 01:16 AM
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.