forced db corruption = media database scavenging
(just a differnt term)
root cause here is still unknown. The best we can get is not properly removing
devices from the SCSI bus.
-----Original Message-----
From: k0s5 [mailto:k0s5 AT YAHOO DOT COM]
Sent: Tuesday, September 03, 2002 12:09 PM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: Re: [Networker] can't fetch old volume error
How to perform the "forced db corruption"?
Recently, our backup server also experience the same problem, can't fetch
old volume
Networker version 6.0.2 on AIX
We are able to get rid of the error by rebuilding the mm directory (media
database scavenging)
But as what the root cause still unknown.
cheers - han
At 8/30/2002 02:22 PM, Graham, Sean wrote:
>I have a server running 6.1.1 on Solaris that has the same issue you
>reported, however on a more frequent basis. We have been able to deduce
>that forcing a shutdown due to hardware errors has been the trigger.
>
>In any event, we have attempted to peform a "forced db corruption" hoping
>that NetWorker can rebuild the media database btrees. This operation was
>never succesful, and we have had to resort to recovering the media
>database from the last known good bootstrap.
>
>I am thinking of moving up to 6.1.2 soon, as other 6.1.2 servers have been
>rather stable.
>
>My $0.02
>
>-Sean
>
>-----Original Message-----
>From: Tim Mooney [mailto:mooney AT DOGBERT.CC.NDSU.NODAK DOT EDU]
>Sent: Friday, August 30, 2002 1:50 PM
>To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
>Subject: [Networker] can't fetch old volume error
>
>
>Our particulars:
>
>Server: Tru64 UNIX 4.0f + patches
>NetWorker: 6.1.1 Power Edition
>Jukebox: STK 9710
>
>
>Since upgrading to NetWorker 6.1.1 in May, we've had two different
>situations where we've seen the message:
>
> nsrjb: Jukebox error: Fri 13:18:07 can't fetch old volume
>
>This message happens with all drives unloaded, in response to the command
>
> nsrjb -HEv
>
>or even
>
> nsrjb -IEv
>
>If I run
>
> nsrck -mv
>
>I immediately get the error:
>
> nsrck: WISS error: too many files created
>
>If I look in /nsr/mm I see:
>
> -rw-r--r-- 1 root system 0 May 3 18:09 .cmprssd
> -rw-r--r-- 1 root system 13 May 10 12:32 .nsr
> -rw-r--r-- 1 root system 0 Aug 27 10:43 cmprssd
> drwx------ 2 root system 8192 Aug 30 13:35 mmvolume6/
> drwx------ 2 root system 8192 Aug 27 10:44 mmvolume6_X0/
> -rw-r--r-- 1 root system 0 Aug 29 10:37 nsrim.prv
>
>
>I wasn't expecting to see the mmvolume6_X0, and it contains a couple temp
>files from early August:
>
> -rw------- 1 root system 0 Aug 11 11:28 temp_2
> -rw------- 1 root system 8192 Aug 12 12:42 temp_2.0
>
>
>The mmvolume6 directory contains about 40 temp* database files, as well
>as the expected client databases, ss databases, and vol databases.
>
>
>When this has happened before I've had to recover the media database from
>the previous bootstrap, and I suppose I'll end up doing that again, but
>
>1) Is there any other way to recover from this particular error? It looks
>like "only" the media database is corrupt, but nsrck isn't helping. The
>last time this happened, I figured I had nothing to lose so I manually
>removed all the temp* database files and tried nsrck -m again, but that
>didn't get me anywhere either.
>
>2) Is anyone else experiencing periodic media database corruption at
>6.1.x?
>
>
>
>We used NetWorker 5.2 for almost four years and never once had media
>database corruption, and now it's happened three times since moving to
>6.1.1. I'm hoping someone else has experienced this and Legato knows
>about it and has a patch that I could request.
>
>Comments and suggestions welcome!
>
>Thanks!
>
>Tim
>--
>Tim Mooney mooney AT dogbert.cc.ndsu.NoDak DOT edu
>Information Technology Services (701) 231-1076 (Voice)
>Room 242-J6, IACC Building (701) 231-8541 (Fax)
>North Dakota State University, Fargo, ND 58105-5164
>
>--
>Note: To sign off this list, send a "signoff" command via email
>to listserv AT listmail.temple DOT edu or visit the list's Web site at
>http://listmail.temple.edu/archives/networker.html where you can
>also view and post messages to the list.
>=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>
>
>**********************************************************************
>This e-mail is the property of Enron Corp. and/or its relevant affiliate
>and may contain confidential and privileged material for the sole use of
>the intended recipient (s). Any review, use, distribution or disclosure by
>others is strictly prohibited. If you are not the intended recipient (or
>authorized to receive for the recipient), please contact the sender or
>reply to Enron Corp. at enron.messaging.administration AT enron DOT com and
>delete all copies of the message. This e-mail (and any attachments hereto)
>are not intended to be an offer (or an acceptance) and do not create or
>evidence a binding and enforceable contract between Enron Corp. (or any of
>its affiliates) and the intended recipient or any other party, and may not
>be relied on by anyone as the basis of a contract by estoppel or
>otherwise. Thank you.
>**********************************************************************
>
>--
>Note: To sign off this list, send a "signoff" command via email
>to listserv AT listmail.temple DOT edu or visit the list's Web site at
>http://listmail.temple.edu/archives/networker.html where you can
>also view and post messages to the list.
>=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
cheers - han
--
Note: To sign off this list, send a "signoff" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
