Re: [Networker] Test recover of a client index?
2011-06-16 12:55:41
On 06/16/11 00:44, bingo wrote:
The question is what you really want:
- To restore the consolidated index backups (the fastest method) nsrck is
the actual procedure
- scanner rebuilds the index from the embedded metadata from each media
where the client data has been backed up to. Of course this takes much longer.
Well, I don't want to recover the index for the purpose of using it. An
index is a save set just like anything else, albeit a special one,
right? I only want to see if I can run a save set recover of an index
and restore it as a file somewhere else to run a test on it. 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? 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?
With save set recover, yes, I could see that it might refuse. I've never
tried it, nor have I tried recovering an index using scanner with raw
recover. I do know that nsrinfo will not give you any information on the
index itself, e.g.:
nsrinfo -t 1308191501 server_name
scanning client `server_name' for savetime 1308191501(Thu Jun 16
02:31:41 2011) from the backup namespace on server server_name
0 objects found
but other save sets, yes, as long as they're still browsable. Just
curious if scanner would do it and if not, why?
George
I do not see a problem to test the recover method:
- make sure that the client index is not used
- check the size with "nsrls client_name"
- rename the /nsr/index/client_name directory
- check with "nsrls client_name" - the expected response is " not found"
- run "nsrck -L2 client" to recreate the index header
- check with "nsrls client_name" - the expected response is " 0 entries"
- recover the CFI with nsrck
- check with "nsrls client_name" - you should now see the old size
- verify whether you can use the CFI during a recovery
- delete the renamed index directory
Not officially supported - but it should work.
+----------------------------------------------------------------------
|This was sent by carsten_reinfeld AT avus-cr DOT de via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------
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
|
|
|