Hi Tim
We use native TSM deduplication (software).
It's generally accepted that you perform one or the other and not both.
This is because additional deduplication results in an additional latency
and often results in zero or negligible improvements. Deduplication
functions as a result of
Since TSM licensing is based on TB's backed up, Will the TSM costs rise
If all the data to TSM's perspective is not deduped?
Tim
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rick
Adamson
Sent: Thursday, 14 May, 2015 9:48 AM
To:
Can anyone provide insight to how they use deduplication within TSM.
TSM with SW based deduplication, no HW deduplication
TSM with no SW based deduplication, using HW deduplication
TSM with both SW and HW deduplication
The only major restriction that I have read is that TSM file based primary
Coincidently I am testing this now. We have historically used Data Domain for
TSM storage using a FILE class storage pool. For best results Data Domain
prefers data uncompressed and unencrypted. If like us you have a capacity
license this tends to significantly increase the reported TSM storage
Tim
This only affects the Capacity license model, not the old PVU model.
In my case all de-duplication and compression is performed by Data Domain on
the back-end and as such TSM is unaware of it.
All data is ingested by the TSM server, and thus reported, as raw data.
Without compression and
