TSM dedup is actually limited to sequential type=FILE storage pools, on disk (A pool with type=DISK is a random-access pool.)
AFAIK, no vendor is doing dedup on tape; when data gets moved out from disk to tape, it is "reduped" or "reinflated", or whatever you want to call it. This actually is sensible. The way dedup works, if a file you back up today has pieces that are the same as a file that you backed up yesterday, the unique parts from today are saved, but for the non-unique parts, only pointers are stored for today's instance of the file. For something like the backup of a large Oracle data base, the amount of new, unique data that you collect every day, could be relatively small. If you keep that up for backups that get migrated out to tape, to do a restore you could end up having to mount every tape in your library. Not good. W On Sat, Nov 7, 2009 at 10:15 AM, Mehdi Salehi <iranian.aix.supp...@gmail.com > wrote: > Hi, > When using de-duplication, am I limited to using disk storage pools? (My > answer is no, because de-duplication is done in software layer) > > Thanks >
