Video Screencast Help

BE2012 - GRT and Deduplication

Created: 03 Sep 2012 | 4 comments
unitofone's picture

Under the advice of Symantec with problems with Backup Exec 2010 deduplication and GRT backups it was recommended to migrate to Backup Exec 2012.

I have an existing case open with symantec now for Backups containing GRT to deduplicated storage, specfically VM backups with File GRT only(Application GRT is just not working so we are ignoring that for now)

We have a MMS Server with a 18TB Deduplication store with 48GB of RAM, and a CASO server with 21TB of deduplicated storage with another 48GB of RAM.

We are finding that small VM's will backup, but large  VM's(440GB seems to be the magical number where stuff starts going wrong) that job rates slow down to an absolute crawl. Symantec are currently investigating.

Under advice for testing we also backed up the same large Virtual Machines to backup to disk. Immedialty we saw big improvments in speed(around 2GB/min to dedupe, 4-7GB/min to B2), then were instructed to try optimised deduplication to the dedupe store, this is where we also encountered problems, a 1TB backup set is currently running at 19 hours to deuplicate to deduplicated storage going at a lazy 220mb/min.

I'm just asking if anyone else is experiencing these problems? I was told the changes in puredisk for Backup Exec 2012 removed a lot of the issues with GRT based backups to it, but I'm finding this doesn't appear to be the case.

Comments 4 CommentsJump to latest comment

pkh's picture

 were instructed to try optimised deduplication to the dedupe store

I think there is some confusion here.  When you backup or duplicate to a dedup store, it is just the plain dedup process. i.e., the data gets dedup'ed.  In terms of the dedup processing, there is no difference between backing up straight to the dedup folder and backing up to a B2D folder and then duplicating to a dedup folder.

Optimised duplication (not dedup) refers to the duplication of data which has already been deduped from one dedup folder to another dedup folder.  In this case, there is no dedup going on.

unitofone's picture

Sorry, my mad, you are correct about optimised duplication.

I'm still unsure why we get fast GRT rates to B2D and big problems with direct to deduplication though.

pkh's picture

When you backup to a B2D folder, BE is just writing the data to disk.  When you backup to the dedup folder, there is a lot of dedup processing going on.  As to the speed difference, you would have to follow-up with Symantec tech support.

bobbyw's picture

Deduplication saves disk space, but at the cost of far slower performance. (at least that's been my experiance and others that I read). I'd LOVE to make it faster somehow.

Our system specs: Server 2008R2 on SSD, Dual Xeon quad core 2ghz, 32GB RAM, 10Gb ethernet, Areca HBA card w/ Dell Powervault w/ dual LTO 5 drives, LSI card w/ 23 disk = 40TB Array for Dedup . It's a powerful setup, never uses more than 12GB of RAM, 30% CPU, and 200MBs on the array. (the array test out at 800MB/s)

How fast is it across 10Gb network to straight to tape? I get 7000-8000MB/'s screams. (these are Veeam backups of VMs being put onto tape). 

Disk to DeDupe: We backup other servers (non VMs) to the dedup volume. My backups to the deduplication volume average 2000-3500MB/min, limited by 1Gb NICs.

DeDupe to Tape: Varies from 800MB/min to 2700MB/min (even with zero disk fragmentation). huh? Why not 7000-8000MB/min? So what's the bottleneck? I've read it's the rehydration of the data before it goes to tape. If this is so, why do I not see my disk IO go crazy on rehydration?