Joerg, I think the brilliant piece W refers to is that you can place a seq. pool inbetween to stop overflow migration. I did not know that either, learning every day from the ADSM-L. Thank you Steve! So I guess we can create an admin schedule to update the NEXT STGPOOL if we don´t want a pool to overflow to tape at certain times. Or just always.Maybe you just want backups to fail, not to use any tape drives and fix things later (enlarge disk pool, adjust schedules etc.) Soooo many knobs we can turn with TSM ;-)
2014-02-03 J. Pohlmann <[email protected]>: > You can chain two sequential pools and use mig stg <name> lo=0 - have used > this technique time and again to change technology, including TSM deduped > to > no-deduped on a dedup appliance so that we got hardware dedup. Have also > used it for tape to file devclass. You can always schedule a mig stg > command > using an admin schedule. > > Regards, > > Joerg > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of > Prather, Wanda > Sent: Sunday, February 02, 2014 12:23 > To: [email protected] > Subject: Re: [ADSM-L] Prevent client backups from failing over to tape > stgpools > > Oh, that's brilliant! > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of > Steven Harris > Sent: Friday, January 31, 2014 8:23 PM > To: [email protected] > Subject: Re: [ADSM-L] Prevent client backups from failing over to tape > stgpools > > Brian > > TSM will only move a backup to the next pool when the pools are disk and > sequential, not when sequential and sequential, so I suggest adding a dummy > sequential pool with no volumes assigned in the middle. > > disk -> dummy -> tape > I've come across this when using an intermediate file pool. It doesn't > spill like a disk pool does should it fill up. > > Regards > > Steve > Steven Harris > TSM Admin > Canberra Australia > > On 31/01/2014 8:24 AM, Skylar Thompson wrote: > > If the tape pool is in a separate device class from other storage pools, > you could set the mount limit on the device class to 0. That's our strategy > when we do library maintenance to allow operations to continue to/from our > disk and file pools. > > > > On Thu, Jan 30, 2014 at 10:47:46AM -0800, Brian Kunst wrote: > >> > >> We???re in a situation where we want to temporarily prevent our users > from ever writing directly to our tape drives. In the event that our > primary random access stgpools hit 100% utilization, we want client backups > to fail rather than failover over to the next, sequential access stgpool. > As far as I can see, there are two ways to accomplish this: > >> > >> 1) Set maxnummp for all nodes to 0. This should prevent them from > access a tape drive when backing up, but would also prevent them from > access > a tape drive to do a restore. Clearly not a good option. > >> > >> 2) Set the Next Storage Pool value for the primary random access > stgpools to null. With this method, migrations would no longer work, but > we > could still move data to tape using the ???move data??? command on the > random access volumes. > >> > >> I???m leaning towards option 2, but I would like to know if anyone cam > think of another way to prevent client backups from going directly to the > tape drives. > >> > >> Thanks, > >> > >> -- > >> Brian Kunst > >> Storage Administrator > >> Large Scale Storage & Systems > >> UW Information Technology > >> > > > > -- > > -- Skylar Thompson ([email protected]) > > -- Genome Sciences Department, System Administrator > > -- Foege Building S046, (206)-685-7354 > > -- University of Washington School of Medicine > > > -- Kind Regards, Groetje, Marcel Anthonijsz
