Networker

[Networker] Networker 7.3 client/server on RHEL 4 - recovery problem

2006-06-19 20:13:01
Subject: [Networker] Networker 7.3 client/server on RHEL 4 - recovery problem
From: Scott Russell <lnxgeek AT US.IBM DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Mon, 19 Jun 2006 20:10:56 -0400
Greets.

I'm looking for another installed environment, that like mine, has Networker 7.3 (or later) on RHEL 4 for both the server and the client. If you have such a beast, could you please test the following for me? I've seen the problem below on both 7.3 stock and 7.3.1 stock.

PROBLEM: Files that are recovered are not the same as the files that are masked for recovery while doing a browse recover.

RECREATE:
1) On the client run "recover -d /var/tmp/recover"
2) In the recover shell, run "add /etc" (do not directly select individual files or do "cd /etc; add *") 3) In the recover shell, run "recover" (Do not do any file selection commands between steps 2 and 3) 4) Look for files recovered into /var/tmp/recover that do not match what is the expected current file according to the existing files in /etc/ or the Networker index.

For example, on several systems I see the following with files that have recently changed:

File in Networker index:
   2222 Jun 14 22:42 /etc/passwd

File actually recovered:
   2054 Jun  1 18:05 /var/tmp/recover/etc/passwd

I think this is tied to having multiple incremental backups after a at least one full backup. If the files recovered haven't been changed since the last full I think everything will be great. If on the other hand, multiple versions of the file exist in the Networker index then possibly the wrong file will be restored.

I appreciate anyone who can confirm they also see this problem. It's driving me batty :) To confirm the some possible FAQs, I've been through my indexes with nsrck and also _can_ recover the correct file if I directly select the individual file in the recover shell. (eg: "cd /etc; add passwd; recover;") Also, saveset recovery appears to have no issue either. Basically the two methods confirm for me that the file is in fact on the tape and can be read successfully depending on how it is selected for recovery.

Odd, eh? I discovered this little issue when attempting to do a bare metal recovery one nice. The system started to run through init and ended up oopsing due to all sorts of odd library combinations!

Thanks for any help!

--
Scott Russell <lnxgeek AT us.ibm DOT com>
IBM Linux Technology Center System Admin

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
wit 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