Wanda,
What about setting up a TSM Library Manager and have him control the library 
and drives for a TSM Library Client doing all the restores.




________________________________
From: Wanda Prather <wprather AT JASI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Sent: Friday, July 10, 2009 1:06:53 PM
Subject: Re: SV: Desperation, DR, and four TS3100 libraries...

Thanks - that's what I suspected!



On Fri, Jul 10, 2009 at 1:01 PM, Bob Levad <blevad AT winnebagoind DOT com> 
wrote:

> Wanda,
>
> We actually tried 2 TS3100s in a test recovery.  It didn't go very well.
>
> If you attempt it.
>
> The Gresham product should be able to present 1 library image to TSM.  I
> don't know at what cost.
>
> Without Gresham:
>
> Make sure your incremental DB backups are directed to disk or someplace
> other than the already overloaded libraries.
>
> If you have a few months to prepare, break the copypool down to several
> that
> will individually fit in a 3100 and give each copypool it's own devclass.
>
> Even though the devclass breakdown is not needed at the home site, it will
> allow you to re-design as needed in a recovery scenario.
>
> Bob.
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Wanda Prather
> Sent: Friday, July 10, 2009 10:31 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] SV: Desperation, DR, and four TS3100 libraries...
>
> Thanks Christian, and everyone, for the suggestions.
>
> Even if I can convince TSM to work with the tapes spread across the 4
> libraries, I think I still lose too much throughput.
>
> If I want to restore multiple clients/filespaces in parallel, I think we
> could easily get into the situation that client 1 is using the drive in
> library 1, and the restore for client 2 needs a tape that is also in
> library
> 1.  The only way  I can see to keep all 4 drives busy is to use them in
> manual mode.  (Short of doing MOVE NODEDATA to guarantee that every client
> is on its own tape, which is highly unrealistic for a copy pool.  Not that
> this scenario is realistic to begin with!)
>
> Thanks everyone!
> Wanda  (maybe another margarita will bring more enlightenment......)
>
>
> On Fri, Jul 10, 2009 at 5:58 AM, Christian Svensson <
> Christian.Svensson AT cristie DOT se> wrote:
>
> > Hi Wanda,
> > On my way to work this morning I have been thinking about your
> > situation and I think I have an idea how you can get it to work. But
> > only for restore not for backup... :) I haven't try this yet and
> > probably don't have time to test it for you. But I think this will
> > work.
> >
> > Define 4 SCSI Libraries
> > Define 4 Drives. 1 to each Library
> > Create 3 NEW Copypool Device Class that is pointing to Library 2,3 and
> > 4 (CopyClass2, CopyClass3, CopyClass4) And Update one Device Class to
> > point to the 1st Library.
> > Now do a Audit of the library with Owner=YOUR TSM SERVER
> >
> > In this stage does TSM know that ALL Tape are available but in
> > different libraries.
> >
> > Technically it should work. The database knows what tape TSM need and
> > only change the data entry-path for the tape in the same way it does
> > with the "primary" (1st) Library you have.
> >
> > This is still just an crazy idea like always that I normally have.
> >
> >
> > Best Regards
> > Christian Svensson
> >
> > Cell: +46-70-325 1577
> > E-mail: Christian.Svensson AT cristie DOT se
> > Skype: cristie.christian.svensson
> > ________________________________________
> > Från: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] för Wanda
> > Prather [wprather AT JASI DOT COM]
> > Skickat: den 10 juli 2009 03:33
> > Till: ADSM-L AT VM.MARIST DOT EDU
> > Ämne: Desperation, DR, and four TS3100 libraries...
> >
> > I'm drawing a blank here, any suggestions welcomed.
> >
> > I have a TSM customer who makes their copypool tapes using a TS3200
> > with
> > LTO4 drives.
> > The TS3200 is a rack-mounted, 2 drive, 40-mumble slot standard ASCII
> > library.  No issues.
> > One copy pool, tapes vaulted and sent offsite.
> >
> > They want to go to a commercial DR vendor site and do a DR test next
> week.
> > The commercial DR vendor, unbelievably, has no multi-drive
> > LTO4-capable libraries.
> >
> > Instead, they want us to use 4 (count 'em, four) TS3100 libraries.
> > The TS3100 is a rack-mounted, 1 drive, 20-mumble slot standard ASCII
> > library.
> >
> > There's only 1 copy pool, so all tapes were created on the same device
> > class.
> > Ignoring the which-carts-would-go-in-which-library issue, I can't have
> > a device class pointing to 4 libraries.
> >
> > And, the TS3100 is built in such a way that unlike a TS3500, you can't
> > open the doors and access the drives for manual mounting.
> > (I'd be happy to pull the covers off and try it, ignoring any
> > warranties I might void, but I doubt the vendor will let me attack the
> > thing with a
> > screwdriver/wrench/hacksaw.)
> >
> > If I put all the carts in one TS3100 that will work, but that leaves
> > me only
> > 1 drive to restore all the clients, and they won't likely get done in
> > the desired time window.
> >
> > The only thing I can think of to use all 4 drives, is to define those
> > four TS3100's as 1 manual library with 4 manual drives, and use the
> > front panel of each TS3100 to move tapes from the I/O slot to the
> > drive when TSM requests a mount.
> >
> > (Actually the FIRST thing I thought of, was "cancel the DR contract,
> > this is nonsense".  But my customer isn't convinced yet...)
> >
> > Anybody got a better solution?
> > I've already tried a margarita, it didn't help....
> >
> > W
> >
>
> This electronic transmission and any documents accompanying this electronic
> transmission contain confidential information belonging to the sender.  This
> information may be legally privileged.  The information is intended only for
> the use of the individual or entity named above.  If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution, or the taking of any action in reliance on or regarding the
> contents of this electronically transmitted information is strictly
> prohibited.
>