|
Re: [Networker] Test recover of a client index?
2011-06-16 17:08:27
On 06/16/11 13:06, A Darren Dunham wrote:
On Thu, Jun 16, 2011 at 12:53:39PM -0400, George Sinclair wrote:
From previous postings, I guess that's not possible. But let's say I
have tape A, and the last save set on there is a client index, and
maybe I'm concerned that there could be something wrong with the
tape, and I want to make sure I can read the last save set on there.
I have tape B, and it contains a clone of that index. I want to
compare them to ensure they're the same, so I recover the one from
the original, generate a listing of all the files and sizes
(including cryptographic checksums) and then recover the one on tape
B and compare the two. I'm not trying to rebuild the index or
integrate it with the one on disk wherein I would use nsrck.
Why could scanner with uasm not work?
The question is how the data is getting saved in the first place. If
it's really just file data read by "save" and the "uasm" module hen it
should work okay. But if it's streamed instead by nsrindexasm, then
recovering into "usasm" won't work.
I just tested recovering a level 9 backup of an index using the
scanner/uasm method, and it worked like a champ. I recovered it on the
snode server. Of course, I have no way of knowing if the data that I got
back is correct because I can't compare it with the real index located
on the primary server since the recovered copy contains only what was
saved for that particular backup instance. It's size, however, does
match what 'mminfo' shows.
Next, I used the scanner/uasm method again to recover an older level
full of the index. This was recovered to a different directory. Once I
had that back, I then created a recursive listing of all the files
(size, mtime and checksum) and then repeated the same recovery again but
this time for the clone volume. I then validated the recovered version
from the clone against the listing - no added, missing or bad matches
found. Clearly, this proves that 1. the data on the original tape is the
same as the data on the clone and 2. I can recover the index. This is
all I wanted to determine.
Here's the command I ran to recover the index to the relocation
directory: /recover_test/scanner/index_test
scanner -s server -f media_file_num -S ssid /dev/nst2 | uasm -rv
-m/=/recover_test/scanner/index_test
Next, I tested recovering the index using a save set recover. That
worked fine, too, and validated perfectly. So I guess the scanner method
was really unnecessary.
It sounds like as a first pass, you could just use scanner and dump it
to a file (no asm necessary). Then repeat and compare. It's a big
opaque file at that point, but is apparently sufficient for your needs?
Yep!
Does NetWorker refuse to do
this when it knows you're recovering an index? How would it know if
you're doing a raw recover as opposed to trying to rebuild the index
from the media entries?
The difference could be the modules that are used to read the stream.
Obviously, neither scanner (with uasm) or save set recover are the
preferred recovery methods for an index. The nsrck -L7 command would be
the first choice, but I didn't want to touch the real index on the
server since there's nothing wrong with the index. I only wanted to
determine if I really could actually read that data on tape and to
ensure that the two copies really are the same.
I suspect that if I created a full backup of an index and then recovered
a copy of it elsewhere (using scanner or save set recover) that they
should compare fine as long as the recovery was done soon after, before
anything changed out there.
However, piecing multiple save set instances of an index together using
save set recover or scanner/uasm (with -rv -i {nNyYrR} option for
overwrite) might not be reliable? Obviously, when recovering normal save
sets, save set recover doesn't remove deleted files like a browsable
recover would, so this might plague recovery of an index, too, and ditto
when using scanner/uasm. Interesting exercise to be left for some other
time.
Thanks!
George
--
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
|
|
|
