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.support AT gmail DOT 
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
>