how to move away from deduplication in the long run

[oskie]

We decided to no longer use deduplication because of the little gain and many issues (TSM bugs) it introduced. What is the best way to get rid of potentially deduplicated data in the long run? Should I just set dedup=no on the storage pool and disable the backup stgpool job, or should I create a new storage pool? I guess the benefit of a new storage pool would be that you'd know when there is 0 deduplicated data (and 0 bitfile issues...).

Has anyone else stepped away from dedup?

Regards,

Oskar Liljeblad (oskar@osk.mine.nu)

[chad_small]

Which dedupe solution were you using? IBM's or EMC's?

[oskie]

TSM's solution

[yuki]

Hi,

Couple of ways... Just update stgpool with DEDUPLICATE=NO, but with that all deduplicated data will remain in stgpool.
Deduplicated files will be discarded during time, reclamation and so on. New backups will not be deduped.

Other way is to migrate data to another storage pool (no deduplication), for example add next stgpool and update deduplicated stgpool migration tresholds to 0.
When migrated, all deduplicated data will be reconstucted. Deduplication is only allowed in file- device class and that's why you can't have deduped tapes

If you like to use same stgpool for backups and not to update copygroups, start with DEDUPLICATION=OFF

[smetter]

I'm curious,

What kind of problems exactly did you run into using TSM6 deduplication?

[dlemieux33]

We're running tests now with TSM dedupe and have seen some savings, so plan to deploy to the QA and production environment where were have TB's of fileserver data.

I'm curious about the kind of data you were deduping, why did you decide to "De-Dedupe"? Performance or lack of savings?