Fixed by Magic... :)

It's amazing what a little DAEMON bouncing of your entire NetBackup
environment will buy you... 

Thanks to everyone for your replies. Sometimes I have to wonder why I still
do this for a living.

~Kate

-----Original Message-----
From: veritas-bu AT jasons DOT us [mailto:veritas-bu AT jasons DOT us]
Sent: Monday, January 13, 2003 4:19 PM
To: Greenberg, Katherine A
Cc: Auburn_list (E-mail)
Subject: RE: [Veritas-bu] Drives down NBU 4.5 MP2




On Mon, 13 Jan 2003, Greenberg, Katherine A wrote:

> I need to clarify a few things....
>
> 1) Everything was working fine until this morning.
> 2) Nothing changed in the environment this morning.
> 3) SSO Tape drives in NetBackup 4.5 do not act the same way they did in
3.4.
> If a drive goes down on one server, unless another server is having
specific
> issues with THAT drive, it will not get down'ed there as well.

This is by design and is one of the touted enhancements in 4.5.

> 4) I've Up'ped the drives about 15 times today, run a test backup
> specifically using the Master's STU and the drives go right back down
again.

What OS are the media servers?  I'm assuming that the master is Solaris
based on the location of your messages file.  Have you tried increasing
the log levels on the master?  bptm would probably be the best place to
start.   Have you looked at Veritas' problem report?

As Mark Donaldson mentioned if you're not using persistent binding it's
possible that a reboot or even SCSI reset ('devfsadm', for example)  of
the master could have changed your drive mappings.  The best way to check
for that is to use robtest to put tapes in the drives one at a time then
eject them, also using robtest.  The move command is issued to the robot
(ie: put tape 1 in drive 1) but the unload is done through the OS (eject
tape /dev/rmt/0) so if things are missmatched you'll notice it there.
eg:  if you tell it to unload drive1 and it ejects drive2 instead.

Another thing to do is use robtest to fill all of your tape drives with
tapes that were successfully writen by your media servers and look under
the drive monitor of the master to make sure that the RVSN matches the
EVSN.   I can go into more detail about this problem, how it happens and
how to fix it if you're interested, but I'm short on time at the moment
and it can get confusing.

> Thanks for the thoughts so far :) Keep 'em coming!

Start by turning up the verbosity of the logs.  The answer may be spelled
out there pretty clearly.  Or, it may not.  Veritas' logging isn't know
for being the easiest to read.

Feel free to contact me off-list if you have any questions or want more
detail.

-Jason

-----
Jason K. Schechner  -   check out www.cauce.org and help ban spam-mail.
=The difference between genius and stupidity is that genius has bounds.=
---There is no TRUTH.  There is no REALITY.  There is no CONSISTENCY.---
   ---There are no ABSOLUTE STATEMENTS   I'm very probably wrong.---


This e-mail, including attachments, is intended for the exclusive use of the
person or entity to which it is addressed and may contain confidential or
privileged information.  If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified that
any dissemination, distribution or copying of this e-mail is prohibited.  If
you think that you have received this e-mail in error, please advise the
sender by reply e-mail of the error and then delete this e-mail immediately.
Thank you.  Aetna