2009-06-18 10:42 AM
Currently to get best results out of deduplication, it's necessary to delete all snapshots from a volume before the initial deduplication pass. (While there is some benefit from dedup regardless, it can't work within data locked in snapshots.)
Might this change in the near future?
2009-06-18 10:45 AM
And...I should have mentioned this originally -- within a SAN environment with SnapManager applications, removing all snapshots can be painful (i.e. SnapManager for Exchange or SQL "backups" that really can't be removed for business SLA reasons).
2009-06-18 10:55 AM
Deleting snapshots is not a requirement, but yes it will yield the best space savings. Alternatively, you can keep the old snapshots and just wait for them to roll off at which time your space will be reclaimed. Going forward, best practice is to dedupe first then take your snaps. Depending on the volume's growth rate, might be easier just to run dedupe on weekends when perhaps no snapshots are scheduled. Also, just an FYI - Provisioning Manager 3.8 (just released) automates the process of scheduling dedupe and also shows stats on dedupe space savings.
2009-06-18 02:25 PM
That will be really awesome (to release blocks in snapshots for de-dupe).
Currently many customers are evaluating de-duplication rather late in their implementation cycle (even for new installations). There are already many existing snapshots & some of them cannot be deleted as base ones for SnapMirror / SnapVault reletionships. So disappointment is common, when a snapshot grows exactly by the same value as the de-dupe saving, effectively leaving free space in the volume as it was... (that's what I noticed few times)
2009-06-26 02:41 PM
Wonderful -- glad to hear it and I'd like to put as much "encouragement" as I can behind the release of said feature (will make deployments much easier....will be nice to not have to have that conversation with customers).