ADSM-L

Re: TSM annoyances

2001-11-06 20:08:09
Subject: Re: TSM annoyances
From: Joe Faracchio <brother AT SOCRATES.BERKELEY DOT EDU>
Date: Tue, 6 Nov 2001 17:05:29 -0800
--------------------------------------------------------------------
P.S.  I want to say start small (reclaim 5 or 10 tapes) but if you have a
P.S.  I want to say start small (reclaim 5 or 10 tapes) but if you have a
system like mine you will find it only makes a small difference whether
you reclaim 10 or 20 offsite tapes because you're still gonna read almost
all of your onsite times to do it!!!!
----------------------------------------------------------------------
> And for Joe Faracchio: I'm also going to look into your method too. The
> 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?

Yes to find the offsite tapes that have been reclamated and needing to be
recalled (and subsequently scratched)  do your command but add
status=pending to it.  So it looks like:

     q vol stg=copypool status=pending acc=offsite

BUT since we keep offsite a 3 week rotation with 2 weeks offsite
(one set there with more recent pending , one (sub)set that's
coming back of older pending, one set going out of newly FULL'd.)

I use a SELECT with a pending > date command.  Like this:

select volume_name,stgpool_name from volumes where stgpool_name='COPYPOOL'
AND access='OFFSITE' and status='PENDING' and pending_date<=%1

%1 in this case is 2 weeks minus a day or two. Or whatever gets me the
oldest pending tapes and not the 1 week younger ones.

BTW: To find the tapes needing to go out we do:

   q vol stg=copypool status=full acc=readwrite .

 We have a policy of only sending FULL tapes out and to mark them
acc=offsite as they are being taken out of robot.  We got this working
before DRM was OK so we've stuck with it and don't use DRM.

> 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?).

With regards to putting them back into use. We found the easiest way that
we can set it up for operators to do is this:

        tapes arrive back as pending offsite location=arcus
        put in library.
        checkin  by volrange with checkl=yes (to make sure they weren't
             degaussed) and (yes) status as private. including 3 DBs
               1  EXPORT.
        upd stg copypool reuse=13 (a number that causes them to go EMPTY
          from pending when they're still marked access=offsite
        upd vol * acc=readwrite wherestatus=empty wherestg=copypool
          (this causes them to immediately go to scratch and you get
           feedback messages for each tape as its changed.

Its a little extra work but I like keeping the most recent PENDING offsite
an extra week.  I plan (if ever) to use them as scratch in a DR.  Have you
asked the question:  What will I use for scratches if I go offsite on a
disaster??? :-)

why would you need to check them out after scratch? we just start using
them!!  If there's more tapes then room in the robot then we just shelf
them as scratches.  In or out of the box they're now scratch.

Hope this helps!!!   :-)

... joe.f.


Joseph A Faracchio,  Systems Programmer, UC Berkeley
Private mail on any topic should be directed to :
         joef AT socrates.berkeley DOT edu
 (510)642-7638 (w)  (209)483-JOEF (M)
                             5633
 the days over.  149 days to retirement!!!!!!!
<Prev in Thread] Current Thread [Next in Thread>