|
Re: [Veritas-bu] Client freezing media.
2009-12-08 18:36:28
You just need to make sure you use
a BIG stick!
From: Jeff Cleverley
[mailto:jeff.cleverley AT avagotech DOT com]
Sent: Tuesday, December 08, 2009 5:30 PM
To: Hudson, Steve
Cc: Judy Hinchcliffe; VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Client freezing media.
They say the definition of
insanity is doing the same thing and expecting different results. I guess
I'm insane. I basically went through all of my steps 3 times checking
different things as I went and at this point in time the media manager database
no longer shows the tapes in bpmedialist and it seems to be backing up normally
again.
I guess if you hit it with a stick enough times it will work :-)
Thanks,
Jeff
On Tue, Dec 8, 2009 at 1:37 PM, Jeff Cleverley <jeff.cleverley AT avagotech DOT com>
wrote:
I have seen the problems like this also, but a tape never
gets loaded. It freezes 60 tapes in less than a couple of minutes.
My library could not load and unload tapes that fast. I've also checked
the device monitor during the failed backups.
The log files never actually say "Loading tape from slot ..."
anywhere. It just says the media is already in the database and asks for
another. Just for kicks I ran a bplabel against a couple of the
tapes. It showed it had the correct label but I told it to over-write
them again.
I think I might try and erase a couple of them to see if that will kick
whatever database entry it has for them. I don't know if that should work,
but it won't hurt :-)
Thanks,
Jeff
On Tue, Dec 8, 2009 at 1:20 PM, Hudson, Steve <Steve.Hudson AT ironmountain DOT com>
wrote:
That is
correct. I have had this same thing happen to me ( All my Scratch tapes got
frozen) when we had drive incorrectly configured….
With that info I would start looking at your drives.
You know that if the drives are configured wrong what you
said happed will happen.
If nb load the tape on drive 2 but the server is looking
for it in drive 3 then they think there is an issue and will freeze the
tape.
So do some checking on the drives on that server and see if
they are still configured correctly.
I've
thought about it but it for the media server since it doesn't show any valid
media. I don't think that it would be anything on the master since it and
the 5 other media servers have no problems using these tapes.
One other thing I noticed the other day. The media server decided not to
backup to itself. It backed up over the network to the master. For
those backups, they ran fine and used the tapes. Some of the backups
within the same session decided to backup to the media server and all failed
with the error 96 after wiping out all my scratch tapes.
If the media database on the media server is corrupt, how can I try and clean
it up? I'm guessing if I wipe it out or move it out of the way i may have
problems doing restores.
Thanks,
Jeff
On
Tue, Dec 8, 2009 at 12:18 PM, <judy_hinchcliffe AT administaff DOT com>
wrote:
My first thought is to run the database consistency check.
Greetings,
I'm going nuts trying to figure out what is happening with one of my SAN media
servers (NBU 5.1, hpux 11.11 servers). Everything was fine on Saturday morning.
Backups went as planned. Saturday night, one of the media servers wiped
out all 65 scratch tapes in the library. On the master I have taken those
media and run the following against each media:
/usr/openv/netbackup/bin/admincmd/bpmedia -unfreeze -m $TAPENAME
echo y | /usr/openv/netbackup/bin/admincmd/bpexpdate -d 0 -m $TAPENAME >
/dev/null
echo y | /usr/openv/netbackup/bin/admincmd/bpexpdate -deassignempty -m
$TAPENAME > /dev/null
/usr/openv/volmgr/bin/vmquery -deassignbyid $TAPENAME $POOLNAME 0
/usr/openv/volmgr/bin/vmdelete -m $TAPENAME
I've then done a vmquery -m $TAPENAME and nothing shows up in a database on
either the master or the media server. I then re-scan the library and the
tapes go back to the scratch pool. When I start a new backup, I find this
in the media server bptm log file:
11:10:22.859 [12387] <2> vmdb_query_scratch_bypool2: server
returned: 1 BK7028 ------ 6 BK7028L2 -------- 8 21 coda 00_021_TLD - 41 0
0 0 0 root root 2 backup scratch 1260295150 1260295814 0 0 0 0 0 0 0 - 0 0 50 0
0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 - ---
11:10:22.860 [12387] <2> db_byid: search for media id BK7028
11:10:22.860 [12387] <2> db_byid: BK7028 found at offset 70
11:10:22.860 [12387] <2> select_media: media id BK7028 just obtained from
Media Manager is already in the media database, requesting a new one
11:10:22.860 [12387] <2> select_media: getting new media id for retention
level 5
It then marks the tape as frozen and wipes everything out again. Where is
the process querying the database at that the vmquery doesn't find? I've
stopped and started all processes on both the master and media server multiple
times.
One thing that does seem odd is the media server vmquery does not show any
valid media. Everything was old. I did a vmdelete of all of
them. After wiping out all the scratch tapes the media manager still
shows no media.
Any help figuring out what bit of corruption it is looking at would be greatly
appreciated.
Thanks,
Jeff
--
Jeff Cleverley
Unix Systems Administrator
4380 Ziegler Road
Fort Collins, Colorado 80525
970-288-4611
--
Jeff Cleverley
Unix Systems Administrator
4380 Ziegler Road
Fort Collins, Colorado 80525
970-288-4611
The information contained in this email message and its attachments is
intended only for the private and confidential use of the recipient(s) named above,
unless the sender expressly agrees otherwise. Transmission of email over the
Internet is not a secure communications medium. If you are requesting or have
requested the transmittal of personal data, as defined in applicable privacy
laws by means of email or in an attachment to email you must select a more
secure alternate means of transmittal that supports your obligations to protect
such personal data. If the reader of this message is not the intended recipient
and/or you have received this email in error, you must take no action based on
the information in this email and you are hereby notified that any
dissemination, misuse, copying, or disclosure of this communication is strictly
prohibited. If you have received this communication in error, please notify us
immediately by email and delete the original message.
--
Jeff Cleverley
Unix Systems Administrator
4380 Ziegler Road
Fort Collins, Colorado 80525
970-288-4611
--
Jeff Cleverley
Unix Systems Administrator
4380 Ziegler Road
Fort Collins, Colorado 80525
970-288-4611
|
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
|
|
