Veritas-bu

[Veritas-bu] STK8500 Issues [SOLVED]

2006-12-27 15:33:42
Subject: [Veritas-bu] STK8500 Issues [SOLVED]
From: SJACOBSO at novell.com (Scott Jacobson)
Date: Wed, 27 Dec 2006 13:33:42 -0700
RE: bpexpdate, see below

>>> "bob944" <bob944 at attglobal.net> 12/27/2006 12:22 PM >>>
Don't want to beat this to death, but IMO, less-experienced NetBackup
admins and the archives will benefit from finding that 

a) this long-running, apparently complicated problem is really NetBackup
config 101 and 

b) there is no behind-the-scenes, undocumented magic that should send a
user off on a fit of bpexpdating.


> On Tue, 26 Dec 2006, bob944 wrote:
> 
> > > [...]
> > > [summary:  the normal misconfiguration:  drive paths and 
> robot drive
> > numbers were not matched correctly]
> > 
> > > ** IMPORTANT NOTE: Something I figured out myself and
> > > then VERITAS confirmed it.  If you have INCORRECT
> > > addressing and you do backups to tapes, when the tapes
> > > are used again, they will try to go the drive that 
> > > originally wrote them--
> > 
> > I don't remember ever observing that, ACSLS or not; 
> > NetBackup uses any drive available in a STU of the right
> > density and media server.  Surely you're not confusing
> > media-server ownership of assigned media, are you?

> Again, the problem only happened when all drives were in use (in the 
> robot).

I don't believe that's correct.  The problem--your configuration mapped
NetBackup drive indices via device names to incorrect
acs/lsm/panel/drive settings--was always there.  The _symptom_ you
saw--hangs and waiting mounts--typically shows up when you throw enough
work at it (your 45 jobs and _multiple media servers_) that MediaServerB
can't use the drive it thinks it has because MediaServerA, through
misconfiguration, has stuck a tape in it.  This or a variation is what
you kept seeing as

   "32 active jobs.  However 1/2 or 3 (random) jobs will hang
   saying 'Mounting MediaID' - I can check ACSLS and run query
   drive *, the tape it is requesting sometimes is and is not
   in the drive that it is supposed to be in, confusing..."

and the reason why experienced ACSLS users' advice has been to verify
the end-to-end configuration and prove it one drive at a time.  Classic
misconfiguration; we've all done it.

> > > EVEN after you fix the addressing 
> > > issue!  They MUST be EXPIRED first with
> > > bpexpdate -d 0 -m MEDIA_ID so they lose that information. 
> > > If at any point you have an addressing problem and write to 
> > > tapes, BE SURE that you EXPIRE ALL TAPES written to during 
> > > that testing phase before you do more testing-- after you
> > > ensure the address/scsi/acsls mapping is correct of course.
> > 
> > Can you cite documentation for this?
> > 
> Unfortunately not; the Veritas engineer confirmed my finding verbally.

That _is_ unfortunate.  I believe you have misinterpreted the situation:
there is no tie between a tape and a physical drive, only the normal
pre-6.0 ownership of media by its media server as long as the media
server has images on it.  Please advise if you do come up with
docs--perhaps a clarifying statement from your Veritas contact--so I and
the rest of the list can learn from it.
Actually this is true and it is tied to the drive index number and has nothing 
to do with ACSLS.
 
If the drives are incorrectly addressed, then backups are run, and then the 
drives are
correctly addressed, those tapes previous written to will upon a next mount 
request will be
mounted into the incorrect drive and result in an error.
 
I too have done this (more times than I care to think about) and when working 
with Veritas
support received the same resolution (going back to 3.1) about using bpexpdate.
 
I don't recall if there was any documentation about this at the time but I'm 
thinking that information
may be stored in the non-dot-f file or in one of the DB's on the media server 
(/volmgr/database).

_______________________________________________
Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu 
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20061227/2f704fa0/attachment.html