John, we tend to run reclaims, moves, and storage pool backups on a daily
basis. Every day, after the storage pool backups finish, we run a database
backup to tape and check out the lot. The database backup and any copypool
tape with any data on it. Once a week we bring tapes back from offsite --
just do a q vol acce=of status=pen,emp to see what comes back.
I check them all in as status=private and let TSM immediately scratch the
empties. The pending tapes will scratch off after the reuse delay expires.
I've a group of perl and shell scripts to automate the entire process, with
a few pool definition tricks thrown in to help - like all my local tape
pools end in '-LT', and all my copy pools end in '-COPY' so I can do this: q
vol stg=*copy acce=readw,reado st=fil,ful and get a list of tapes to check
out. Likewise, the retrieval script starts out with 'q vol acce=of
st=pen,emp'; I strip off just the volume numbers and print it for our
courier. Note that you need some other technique to manage the database
backup itself (ours is warped but works real well :-)
Tom Kauffman
NIBCO, Inc
> -----Original Message-----
> From: Johnn D. Tan [mailto:jdtan AT MED.CORNELL DOT EDU]
> Sent: Tuesday, November 06, 2001 1:54 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: TSM annoyances
>
>
> Yes! It does work for TSM 4.x! This is great! Saves us a heck of a lot
> of back and forth trips up to our library.
>
> And for Joe Faracchio: I'm also going to look into your
> method too. The
> only question is, at the end of the reclamation, how do you know which
> 15-30 tapes got reclaimed? Do you just do a "q v
> stg=[offsite-backup-copy-name] acc=offsite" and look for 0.0%/Empty?
>
> I assume you can then just checkin these volumes as "scratch"
> (or do you
> have to check them in as private, do a delete, and then check them out
> again?).
>
> Now if I can just sync up the home elements and the slot numbers, I'll
> be able to change my subject line ;).
>
> Thanks again to everyone for the help!
> johnn
>
> On Monday, November 5, 2001, at 10:14 AM, Kauffman, Tom wrote:
>
> > This has worked for me since I started with ADSM 2.1. I'll
> admit that
> > they
> > may have broken it in TSM 4.x -- but I just fired up a "move data
> > <offsite
> > volser>" and TSM is cheerfully mounting the original storage pool
> > volumes to
> > put the data on a new tape for the off-site copy pool. I'm
> running TSM
> > 3.7.4
> > on AIX 4.3.3.
> >
> > I've had to do this for some time, as I've had DLT tapes
> (and now LTO)
> > and
> > reclaim at xx% gets ugly when you want to recover a 50% full (and
> > filling)
> > LTO tape that has 48 GB on it but do not want to reclaim a
> 50% full (and
> > full) LTO tape that hit 420 GB and now has 210 GB to reclaim.
> >
> > Here's what I've got going right now:
> >
> > adsm> move data 001351
> > ANR2232W This command will move all of the data stored on
> volume 001351
> > to
> > other volumes within the same storage pool; the data will be
> > inaccessible to
> > users until the operation completes.
> >
> > Do you wish to proceed? (Yes/No) y
> > ANS8003I Process number 3472 started.
> >
> >
> > 3,472 Move Data Offsite Volume 001351 (storage pool
> >
> > INCR-LT-COPY), Target Pool
> INCR-LT-COPY,
> > Moved
> > Files: 0, Moved Bytes: 0, Unreadable
> > Files:
> > 0,
> > Unreadable Bytes: 0. Current Physical
> > File
> >
> > (bytes): 911,150,749
> >
> > Current input volume: 001311.
> >
> > Current output volume: 001250.
> >
> > ANR1157I Removable volume 001311 is required for Move Data process.
> > ANR8324I LTO volume 001311 is expected to be mounted (R/O).
> > ANR8337I LTO volume 001250 mounted in drive DRIVE_10 (/dev/rmt9).
> > ANR1340I Scratch volume 001250 is now defined in storage pool
> > INCR-LT-COPY.
> > ANR8337I LTO volume 001311 mounted in drive DRIVE_02 (/dev/rmt1).
> >
> > adsm> q vol 001311
> >
> > Volume Name Storage Device Estimated Pct
> > Volume
> >
> > Pool Name Class Name Capacity Util
> > Status
> >
> > (MB)
> > ------------------------ ----------- ---------- --------- -----
> > --------
> > 001311 NT-LT NIBLTO 190,091.7 91.0
> > Full
> >
> >
> > adsm> q vol 001351
> >
> > Volume Name Storage Device Estimated Pct
> > Volume
> >
> > Pool Name Class Name Capacity Util
> > Status
> >
> > (MB)
> > ------------------------ ----------- ---------- --------- -----
> > --------
> > 001351 INCR-LT-CO- NIBLTO 172,746.9 54.4
> > Filling
> >
> > PY
> >
> >
> > Tom Kauffman
> > NIBCO, Inc
> >
> >> -----Original Message-----
> >> From: Gabriel Wiley [mailto:wileyg AT US.IBM DOT COM]
> >> Sent: Monday, November 05, 2001 9:01 AM
> >> To: ADSM-L AT VM.MARIST DOT EDU
> >> Subject: Re: TSM annoyances
> >>
> >>
> >> Unless something happened over night, that I have yet to
> hear about.
> >>
> >> "John, you don't need to bring copypool tapes back on site to
> >> reclaim them.
> >> Just do a "move data" on the off-site volume and TSM will
> >> rebuild it from
> >> the original tapes in the library."
> >>
> >> This statement would be false: If you are going to "move data" the
> >> off-site or what ever tape/data you are moving will have
> to be in the
> >> library.
> >>
> >> If you are going to "Reclaim" , the off-site/copy pool tape
> >> would not need
> >> to be present in the Library.
> >>
> >> Gabriel C. Wiley
> >> ADSM/TSM Administrator
> >> AIX Support
> >> Phone 1-614-308-6709
> >> Pager 1-877-489-2867
> >> Fax 1-614-308-6637
> >> Cell 1-740-972-6441
> >>
> >>
> >> "Kauffman, Tom" <KauffmanT AT NIBCO DOT COM>@VM.MARIST.EDU> on
> >> 11/05/2001 08:22:13
> >> AM
> >>
> >> Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> >>
> >> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> >>
> >>
> >> To: ADSM-L AT VM.MARIST DOT EDU
> >> cc:
> >> Subject: Re: TSM annoyances
> >>
> >>
> >> John, you don't need to bring copypool tapes back on site to
> >> reclaim them.
> >> Just do a "move data" on the off-site volume and TSM will
> >> rebuild it from
> >> the original tapes in the library.
> >>
> >> Tom Kauffman
> >> NIBCO, Inc
> >>
> >>> -----Original Message-----
> >>> From: Johnn D. Tan [mailto:jdtan AT MED.CORNELL DOT EDU]
> >>> Sent: Friday, November 02, 2001 7:39 PM
> >>> To: ADSM-L AT VM.MARIST DOT EDU
> >>> Subject: Re: TSM annoyances
> >>>
> >>>
> >>> 1. Yet their device support website
> >>>
> >>
> (http://www.tivoli.com/support/storage_mgr/devices/all.html) lists the
> >>> element matrix for Gator, where slot 1 is element 1, but
> >> TSM actually
> >>> sees it as 1 + 29, or 30. And drive 1 is supposed to be
> 646, but TSM
> >>> sees it as 646 + 29, or 675. Again, despite their own matrix,
> >>> TSM seems
> >>> to have added 29 to the element addresses they list.
> >>>
> >>> 2. The reason I do "move data" is to consolidate the data that is
> >>> offsite. So, if I have a volume offsite that is
> >>> "under-utilized" (let's
> >>> say only 22% utilized), then I would want to check that tape
> >>> in, and do
> >>> a "move data" onto a pool-copy "filling" tape. But it won't
> >>> let me do a
> >>> "move data" unless the tapes associated with that one are
> >> also in the
> >>> library.
> >>>
> >>> 3. Yes, as I mentioned, it's most likely a SpectraLogic
> issue. Just
> >>> wanted to see if other folks were having similar issues.
> >>>
> >>> johnn
> >>>
> >>>
> >>>
> >>> On Friday, November 2, 2001, at 05:04 PM, George Lesho wrote:
> >>>
> >>>> 1.,The element numbers below 31 are associated with bulk
> >>> load, I/O port
> >>>> and
> >>>> other functions on my IBM 3575L32 Magstar tape library.
> >> Not Tivoli's
> >>>> fault
> >>>> or responsibility how the element numbers are mapped.
> >>>> 2. I let TSM worry about where it sticks the data on the tapes
> >>>> 3. Speak to your library vendor and ask them why their
> >> device driver
> >>>> microcode doesn't work right. The IBM Magstar doesn't
> >>> behave this way.
> >>>>
> >>>> George Lesho
> >>>> AFC Enterprises
> >>>> Storage/System Admin
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> "Johnn D. Tan" <jdtan AT MED.CORNELL DOT EDU>@VM.MARIST.EDU> on
> >> 11/02/2001
> >>>> 03:47:23 PM
> >>>>
> >>>> Please respond to "ADSM: Dist Stor Manager"
> <ADSM-L AT VM.MARIST DOT EDU>
> >>>>
> >>>> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> >>>>
> >>>>
> >>>> To: ADSM-L AT VM.MARIST DOT EDU
> >>>> cc: (bcc: George Lesho/Partners/AFC)
> >>>> Fax to:
> >>>> Subject: TSM annoyances
> >>>>
> >>>>
> >>>> I have a few annoyances with Tivoli -- not many, as it's a great
> >>>> product, just a handful.
> >>>>
> >>>> 1) We have TSM 4.1.3 server connected to SpectraLogic
> Gator/64000.
> >>>> Despite what Tivoli says on their website, the element
> >>> number of Slot 1
> >>>> in the library is not 1, but 30! This is very annoying!
> >> If I do a "q
> >>>> libv lib1" and look up a volume's home element, I have to
> >>> subtract 29 in
> >>>> order to really know what slot it's in on the library.
> Can this be
> >>>> corrected so that it is what Tivoli's website says it
> >>> should be -- i.e.,
> >>>> element 1 matches slot 1?
> >>>>
> >>>> 2) Is there a simple way to find out which volumes are
> >>> associated to any
> >>>> other? For instance, let's say I have to do a "move data"
> >> on 000115.
> >>>> Right now, here's what I do:
> >>>> q content 000115 count=-1 f=d
> >>>> q content 000115 count=1 f=d
> >>>> If either one of these has a segment 1/1, then
> >> everything's
> >>>> great,
> >>>> as there is no associated volume. But if either or both
> >> have 1/2 (or
> >>>> 2/2) then I have to issue:
> >>>> audit v 000115
> >>>> And find the associated volume. The catch is, if
> >>> there are *two*
> >>>> associated volumes, you have to check one of them in first
> >>> and update
> >>>> its status, before you can do another audit to find the
> >>> other associated
> >>>> volume.
> >>>> Is there any way to find these associated volumes
> >>> in one swift
> >>>> command?!
> >>>>
> >>>> 3) [I think this is more a SpectraLogic issue, but I'll gripe
> >>>> anyway ;).] When I want to "bulk load" a bunch of tapes
> >>> into the Gator
> >>>> tape library, I have to make sure no tapes are mounted in
> >>> the drives.
> >>>> Otherwise, the bulk load will just blindly put the new
> >>> tapes into the
> >>>> slots of the tapes in the drive. Doesn't TSM "talk" to the
> >>> tape library
> >>>> and tell it the home elements (or slots) of the tapes that
> >>> are mounted
> >>>> in the drives, so that the robotic picker won't put tapes
> >> into those
> >>>> slots??
> >>>>
> >>>> Thanks for any advice.
> >>>> johnn
> >>>>
> >>>
> >>
> >
>
|
