Forum Discussion

OP's avatar
OP
Level 4
13 years ago
Solved

BE2012 - Duplicate from DeDup Device is VERY slow

Hopefully someone can help me - I'm running out of ideas:

Problem:

We're using DeDuplication for the firststage-backup, afterwards the data is copied to external media - this time USB-disks (USB3 with USB3-controller)
The first stage is running fine, but the copy to usb is awfully slow - and gets slower every day.

It started with about 1400 MB/min, now it's down to 150-250 Mb/min.

To have a comparison to a "normal" duplicate to usb-job, I've created a b2d-device on the same storage as the dedup-foleder, made a backup and duplicated that to usb-disk - everthing identical, except the b2d-device used as a source instead of the dedup-device.

The result is about 6.000-7.500 MB/min - so the diskchannel and the usb-disk-channel is fine.

I don't have a problem with the slower speed from the dedup-device (due to the rehydrating) - as long it stays above 1000 MB/min, but it mustn't drop that far.

Environment:

BE2012 with actual updates. The hardware is a HP DL180G6, CPU: E5606, 12 GB RAM. 5 SAS 1 TB Harddisks attached to an HP SmartArray P410 with 256 MB Cache and battery. CPU usage below 50%, RAM-usage ~ 50%.

 

Any idea ?

Thx

Olaf

2012
Backing Up
Backup and Recovery
Backup Exec
Deduplication Option
  • OP's avatar
    OP
    12 years ago

    Hi folks!

    I just wanted to update and close this case.

    To make a very long story short:
    According to the 1st, 2nd and 3rd level supportengineers from Symantec  we do not have a problem - the dedup works like designed and they can NOT do anything to speed up the process of dplicating FROM the dedup to any external non-dedup-device. :-((

    Due to this sad result and the amount of time we've invested in this case we've decided to discard dedup as a primary backup target at our and all customer site's.

    From my point of view the product can't keep the expectations from the customers and promisses made by symantec.

     

    CU

    Olaf

  • CraigV's avatar
    CraigV
    Moderator
    13 years ago

    Unless you're duplicating to another dedupe folder, you should actually be rehydrating your data...this is 1 reason for slower speeds. Add in a USB drive and you would have the right environment for slow duplication rates.

    The server hardware itself looks to be fine, with no changes to be made!

    Thanks!

  • OP's avatar
    OP
    Level 4
    13 years ago

    The absolut speed of the (beginning) dedup rate isn't the problem.

    THe quesion is - why is it getting slower every day?

    Without any visible bottleneck regarding disk, cpu or ram ?

    Imho that's not the way it should be.

    Olaf

  • CraigV's avatar
    CraigV
    Moderator
    13 years ago

    Have you used Perfmon.exe to see whether or not there is a bottleneck on that USB drive?

    Thanks!

  • OP's avatar
    OP
    Level 4
    13 years ago

    I'm pretty sure, that the usb-disk is not the botteneck due to 2 facts:

    - Copy from B2D to USB works with ~ 7.000 MB/min

    - Copy from DeDup to USB worked in the past with more than 1.500 MB/min.

    I haven't used perfmon but the ressourcemonitor in the w2k8 task manager and couldn't see any problems.

     

    Regards

    Olaf

  • CraigV's avatar
    CraigV
    Moderator
    13 years ago

    ...please edit your previous post if you post within minutes of the last one!

    Thanks!

  • AshutoshTamhank's avatar
    AshutoshTamhank
    Level 4
    13 years ago

    As a test what happens when you do a duplicate from your dedupe back to the dedupe folder?

    Is that a GRT / non GRT enabled backup you are duplicating?

  • OP's avatar
    OP
    Level 4
    13 years ago

    Its a duplicate of a backup from a w2k8-server - raws based.

    It includes Exchange-Data/mailboxes - so the answer is yes and no.

    Does that make any difference ?

  • AshutoshTamhank's avatar
    AshutoshTamhank
    Level 4
    13 years ago

    When a backupset is duplicated from a dedupe device to a non dedupe device, data is rehydrated i.e reconstructed. The metadata(catalogs) also has to be rebuilt. GRT backups are catalog intensive than a non GRT backup. To isolate the issue, I would suggest you to create a backup without GRT and test a duplicate backup. I assume there are no other operations running on the dedupe folder during the duplicate backup.