In regard to: [Networker] media database problem, Athanasios Douitsis said...:
Hello all,
Please accept my sincerest apologies if this problem has been mentioned
again on this list, due to its complexity I couldn't figure out
if it has or not by using the search function of the list.
I just did a backup of some servers to a pool destined for offsite storage
(this means that I instructed the pool not to save indexes for the save sets)
and while trying to verify that save sets are recoverable I noticed this:
The mminfo command for a specific client yields:
volume client name ssid clone id
retent total volid
Offsite.001 host1 /var 3103859202 1119420706
06/22/2006 17254492048 3103667713
Offsite.002 host1 /var 3103859202 1119420706
06/22/2006 17254492048 3106030849
Offsite.003 host1 /var 3103859202 1119420706
06/22/2006 17254492048 3108239105
Offsite.004 host1 /var 3103859202 1119420706
06/22/2006 17254492048 3110400001
It would help if you showed the mminfo command you used. I'm assuming it
has a report argument of
-r volume,client,name,ssid,cloneid,ssretent,totalsize,volid
I don't see anything wrong with the output shown, though. It indicates
you have a single saveset (ssid=3103859202,cloneid=1119420706) that spans
four volumes.
and when I try to go to save set->recover the above ssid from the nwadmin the
restoration fails saying:
NetWorker media: (emergency) cannot find volid 3108239105
...without even bothering to tell me to insert some tape.
That however is a problem. What happens when you run media-only
queries, such as:
mminfo -q volid=3108239105 -r 'volume,state,location,savesets'
Please note that trying to get info on the save set results in an error box
saying that info on
the save set and the volume cannot be found. Trying to do the same using the
recover command
line command has the same results.
To me it looks like some sort of abnormal media database entries issue. Has
anyone encountered anything
similar? If yes, was there some form of workaround or fix?
The entries you show look fine; it's one saveset that spans four volumes.
Have you tried using `nsrck', specifically with `-L6'?
Other things you could try include removing that volume (or all of those
volumes) and using `scanner -m' to rebuild the media index from the tape
contents.
You could also try a media database scavenge. The procedure for
performing a scavenge has been posted to this list a couple times, search
the archive for more information. Alternately, you might also be able to
find the procedure on Legato's site.
Using nsrck and doing a media database scavenge are about the only
ways I know of to fix consistency issues in a media database, short
of starting over from scratch.
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 networker" command via email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
| 