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:[email protected]] On Behalf Of Karel Bos Sent: Wednesday, June 05, 2013 2:10 AM To: [email protected] 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 <[email protected]> Verzonden: dinsdag 4 juni 2013 20:53 Aan: [email protected] 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
