Because of this, and if you want to use TSM dedup, you could access your 
storage over NFS as a FILE device pool.  That is, instead of using a VTL 
interface over fiberchannel you could bring up a NFS server on the Linux box 
and access it as a TSM FILE device pool over ethernet.  

Whether to use TSM dedup or VTL sftw dedup may depend on which provides better 
dedup ratio.  You might want to perform a test with a large sample of your data 
to see what ratio you get with each.  


Rick




-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Ehresman,David E.
Sent: Friday, June 13, 2014 7:53 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: TSM and VTL Deduplication

Just so we're all clear here.

You cannot TSM dedup to virtual tape, even though the virtual tape is actually 
disk.  TSM dedup has to go to a TSM defined FILE storage pool, not a TSM 
defined tape storage pool.

If you write to a virtual tape storage pool, the data will be written to those 
virtual tapes un-deduped by TSM.  It the virtual tape does dedup, it will do so 
but TSM will have no part in that operation and will in fact not know that it 
has been done.

David

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Dan 
Haufer
Sent: Thursday, June 12, 2014 4:31 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] TSM and VTL Deduplication

Yes, one of the two. If TSM deduplication is enabled and the target is a 
virtual tape, i doubt if the VTL can deduplicate anything from the write data.

--------------------------------------------
On Thu, 6/12/14, Ehresman,David E. <deehr...@louisville.edu> wrote:

 Subject: Re: [ADSM-L] TSM and VTL Deduplication
 To: ADSM-L@VM.MARIST.EDU
 Date: Thursday, June 12, 2014, 12:51 PM
 
 Unless you have a
 specific requirement, I would suggest you choose either TSM  dedup to disk or 
go straight to virtual tape.  There is not  usually a need to do both.
 
 David
 
 -----Original Message-----
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU]  On Behalf Of Dan 
Haufer
 Sent: Thursday, June
 12, 2014 2:41 PM
 To: ADSM-L@VM.MARIST.EDU
 Subject: Re: [ADSM-L] TSM and VTL
 Deduplication
 
 Thanks for
 all the answers. So SSDs (Looking at  SSD caching) for the  database storage 
and 10GB  per TB of total backup data on  the safer side. 
 
 --------------------------------------------
 On Thu, 6/12/14, Erwann Simon <erwann.si...@free.fr>
 wrote:
 
  Subject: Re:
 [ADSM-L] TSM and VTL Deduplication
  To: ADSM-L@VM.MARIST.EDU
  Date: Thursday, June 12, 2014, 8:47 AM
  
  Hi,
  
  I'd rather say 6 to 10 times, or 10 GB  of
  DB for each 1 TB of data (native, not
 deduped) stored.
  
  --
  Best
  regards / Cordialement /
 مع تحياتي
  Erwann SIMON
  
  -----
  Mail
 original -----
  De: "Norman
  Gee" <norman....@lc.ca.gov>
  À: ADSM-L@VM.MARIST.EDU
  Envoyé: Jeudi 12 Juin 2014 16:55:29
  Objet: Re: [ADSM-L] TSM and VTL
  Deduplication
  
  Be prepare
  for your database
 size to double or triple if you are using
 
 TSM deduplication.
  
 
 -----Original Message-----
  From: ADSM: Dist
 Stor Manager [mailto:ADSM-L@VM.MARIST.EDU]
  On Behalf Of Prather, Wanda
 
 Sent: Thursday,
  June 12, 2014 7:15 AM
  To: ADSM-L@VM.MARIST.EDU
  Subject: Re: TSM and VTL Deduplication
  
  And if you are on the
  licensing-by-TB model, when it gets un-deduped  (reduped,
  rehydrated, whatever), your costs
 go up!
  
  -----Original
 Message-----
  From: ADSM: Dist Stor Manager
 [mailto:ADSM-L@VM.MARIST.EDU]
  On Behalf Of Dan Haufer
  Sent:
 Thursday, June
  12, 2014 9:48 AM
  To: ADSM-L@VM.MARIST.EDU
  Subject: Re: [ADSM-L] TSM and VTL
  Deduplication
  
  Understood.
  Thanks !
  
 
 --------------------------------------------
  On Thu, 6/12/14, Ehresman,David E. <deehr...@louisville.edu>
  wrote:
  
  
 Subject: Re:
  [ADSM-L] TSM and VTL
 Deduplication
   To: ADSM-L@VM.MARIST.EDU
   Date: Thursday, June 12, 2014, 5:33 AM
  
   If TSM moves data from
 a
   (disk) dedup pool to tape, TSM has to  un-dedup
  the data as  it reads it
 


-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.

Reply via email to