|
Re: [Networker] Why isnt this browsable?
2012-04-02 12:43:37
On 2012-04-02 08:23, Michael Leone wrote:
Michael,
it is browseable from the status. That's what mminfo tells you.
However the index is empty. You can verify this with "nsrls client".
Yes, but why? The index should have been rebuilt with "scanner -i".
I agree. But what would happen if you instead scanned the tape to get
the ssid (assuming you don't already know it), and then you used scanner
to perform a raw recover using uasm and relocated it to another target
directory, just to check, and then maybe moved it into place. Would that
work?
On a few occasions, I have tested recovering indexes manually using save
set recover (-S ssid/cloneid) but recovering them to another directory
on another client and *not* the primary backup server. This was just a
test to see what would happen. I experienced no problems, but I didn't
do anything with the recovered index. I just verified that its size and
nfiles agreed with what the media database reported, and then I deleted
the recovered index. Of course, in this example, the media database
already had an entry for this save set, so it's not as if this came from
another server as in your case. However, I have also on at least
occasion in the past performed a raw recover of an index wherein I used
scanner, specified the ssid and used 'uasm' to do a raw recover of the
index. I *think* I then verified the recovered index by generating a
checksum listing of the entire directory and compared it with the
original one located on the backup server (/nsr/index/index_name). As I
recall, everything validated. Again, this was recovered to another
location, just as a test, and the index was listed in the media database
since it didn't come from another server. But scanner shouldn't care,
should it?
Another possibility would be to rebuild just the media database entry
using the '-m' option and leave off the '-i' option. Then use save
recover to recover the index. I know 'nsrck -L7' is what they say to
use, but why could an index not be recovered using save set recovery? Is
that absolutely set in stone? I think using 'nsrck -L7' merges the
recovered information into the already existing index with no overwrite,
so you have everything you started with plus the recovered stuff (in
most cases that's exactly what you want), but in your case your index is
empty, so I would think that a save set recover couldn't overwrite
anything since there's nothing in there to overwrite. So the danger in
doing a save set recover seems moot here. It there something I'm missing
with that inference?
What about the browse time on the NSR client resource. Does that need to
be increased to accommodate the recovered index information? Been a long
time since I've done a realy recovery of an index. And are you sure you
specified the same clientid when you created it?
Also, check the ssretent, ssbrowse, clretent, ssexp values to ensure
that they really do reflect a future date as you indicated. Maybe nsrmm
does need to be used to reset these.
George
As i mentioned in my response on 03/26, this may happen due to a
known problem. You better follow my advise to monitor the end of
EACH scanned save set carefully.
There is only one tape, in this instance. This is a different problem from
the one I mentioned earlier - this one tape was made by a different NW
server than even the tapes made by a different NW server that I mentioned
before. :-) The previous problem was with savesets that spanned multiple
tapes; this problem is with a saveset completely contained within one
tape.
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the body of the email. Please write to networker-request
AT listserv.temple DOT edu if you have any problems with this list. You can access the
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
--
George Sinclair
Voice: (301) 713-3284 x210
- The preceding message is personal and does not reflect any official or
unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the body of the email. Please write to networker-request
AT listserv.temple DOT edu if you have any problems with this list. You can access the
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
|
|
