I am in the process of building/testing this config right now,
with the intention of migrating from my current Solaris 7.2.1
server to RHEL4/7.3.1.

Once I get it going, I will test it to see if I can duplicate
the problem you are seeing.

Rodney

Scott Russell wrote:

Just a follow up post to see if anyone has a similar environment as I
describe below. The client and server do not need to be on different
systems. I've been able to replicate the problem below using Networker
7.3.1 server/client on the same RHEL4 system.

I'm curious, am I really the only one running 7.3.x on RHEL4 or have a
few of the Linux admins tried this but were unable to replicate the problem?

Any help much appreciated.

Scott Russell wrote:
 > 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.

--
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 <http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER>

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