I have been sending mine to Data Domain for a couple of years now, I did create 
a separate replication context for it to our DR facility.

Also, have tested TSM server recovery successfully using this config.
Very fast. I have warm standby servers that have TSM installed and minimally 
configured. Mean time to recovery for 5 TSM servers is approximately 20 minutes.

~Rick

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Karel Bos
Sent: Wednesday, June 05, 2013 2:10 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] DB backups in v6 land. And, BACK DB dedupdev=yes... ?

Hi,

I think doc stated not to use dev=file shared=yes for TSM db backups. From 
memory it didn't specify why, but easy to setup dedicated file dev for tsm db 
backup only. DDM doesn't care anyways, it does dedup over all data stored in it.

Kind regards,
Karel


----- Oorspronkelijk bericht -----
Van: Allen S. Rout <asr AT UFL DOT EDU>
Verzonden: dinsdag 4 juni 2013 20:53
Aan: ADSM-L AT VM.MARIST DOT EDU
Onderwerp: [ADSM-L] DB backups in v6 land.  And, BACK DB dedupdev=yes... ?

So, the doc suggests that you shouldn't use this for FILE devclasses.
Anybody know anything about why?

Similarly, it talks about that feature being good for VTL applications, but is 
quiet about TSM virtual volumes.  Seems odd; the dedupe optimization would seem 
to be relatively generic, if it's not just for [product X].

I'm musing about sending my DB backups straight to a Data Domain, and syncing 
that offsite.  It'd take away one level of indirection from my DR planning.


- Allen S. Rout