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 >
