frecover failing from NFS client

[skt_skt]

NFS file system were tape is attached; HP-UX 11
adedd13n:root [/root] mount|grep -i nfs
/TMP_NFS_ARCHIEVE on adedd04p:/str_edi_prdr/app01/gentran61/gsprod rsize=32768,wsize=32768,proto=udp,NFSv3 on Thu Nov 27 06:43:07 2008

File is readable from the NFS client. For example.

adedd13n:root [/grab_tools] file /TMP_NFS_ARCHIEVE/LEGAL_IN/STERLING/ster.4008498.081016011001.gz
/TMP_NFS_ARCHIEVE/LEGAL_IN/STERLING/ster.4008498.081016011001.gz: gzip compressed

SOurce server where the original file system resides ; HP-UX 11.00
adedd04p:root [/root]uname -a
HP-UX adedd04p B.11.00 U 9000/800 130424696 unlimited-user license

File system exported with
#exportfs -i -o root=adedd13n /str_edi_prdr/app01/gentran61/gsprod

Fbakcup command used from NFS client

#fbackup -vf /dev/rmt/c0t2d0BESTn -i LEGAL_IN -i LEGAL_OUT -I /grab_tools/index_fbackup1 -n

Here is the index file clarifying file was in backup.

adedd13n:root [/grab_tools] grep ster.4008498.081016011001.gz index_fbackup1
188 1 LEGAL_IN/STERLING/ster.4008498.081016011001.gz

failed recover command. (tried -xvf and -xvFf)

adedd13n:root [/home/kumarts] frecover -xvf /dev/rmt/c0t2d0BESTn -i /TMP_NFS_ARCHIEVE/LEGAL_IN/STERLING/ster.4008498.081016011001.gz
frecover(4301): /TMP_NFS_ARCHIEVE/LEGAL_IN/STERLING/ster.4008498.081016011001.gz not recovered from backup media

Fbackup did not thorugh any warning/error. But frecover failed restore but w/o any specific error.

Any one faced similar option.

Also while the backup was taken for a single file; we were able to restore with -F option on frecover(otherwise failes with same error reporteded earlier.Note that we has waring about the only the file got backedp up and not the immediate to parent subdirectoried; that is why we used -F while restoring the single file)

#fbackup -vf /dev/rmt/c0t2d0BESTn -i /TMP_NFS_ARCHIEVE/LEGAL_IN/STERLING/ster.4007559.081016001001.gz -I /home/chatta2/testbackupindex1 -n

this restores to the current working directory.

#frecover -xvFf /dev/rmt/c0t2d0BESTn -i /TMP_NFS_ARCHIEVE/LEGAL_IN/STERLING/ster.4008498.081016011001.gz

any hints would be appreciated; The whole backup run almost a day. So each test is time sensitive if tried with whole file system.

Let me know if an sugeeetion or any more info is required

[Steven E. Protter]

Shalom,

Check that the target filesystem has largefiles enabled. Use fsadm to check the target filesystem

SEP

[skt_skt]

tried on both largefiles/nolargefiles enabled FS both failed.

[OldSchool · Accepted solution]

Item One:


"#fbackup -vf /dev/rmt/c0t2d0BESTn -i LEGAL_IN -i LEGAL_OUT -I /grab_tools/index_fbackup1 -n

Here is the index file clarifying file was in backup.

adedd13n:root [/grab_tools] grep ster.4008498.081016011001.gz index_fbackup1
188 1 LEGAL_IN/STERLING/ster.4008498.081016011001.gz

failed recover command. (tried -xvf and -xvFf)

adedd13n:root [/home/kumarts] frecover -xvf /dev/rmt/c0t2d0BESTn -i /TMP_NFS_ARCHIEVE/LEGAL_IN/STERLING/ster.4008498.081016011001.gz
frecover(4301): /TMP_NFS_ARCHIEVE/LEGAL_IN/STERLING/ster.4008498.081016011001.gz not recovered from backup media "
======================================================

In the above example, it appears that you wrote "LEGAL_IN" and "LEGAL_OUT" to the tape (fbackup)...and attempted to restore objects named "/TMP_NFS_ARCHIVE......". The objects are named LEGAL_IN / LEGAL_OUT, not /TMP_NFS_ARCHIVE.

If you cd to /TMP_NFS_ARCHIVE and then run your frecover as follows, I *believe* it will bring them back as expected:

frecover -xvf /dev/rmt/c0t2d0BESTn -i LEGAL_IN

======================================================
======================================================


Item Two:

"Also while the backup was taken for a single file; we were able to restore with -F option on frecover(otherwise failes with same error reporteded earlier.Note that we has waring about the only the file got backedp up and not the immediate to parent subdirectoried; that is why we used -F while restoring the single file) "


======================================================

NOTE: I don't have access to a system right this minute, so I'm going from memory and the "man" pages

If I understand your meaning, then either you or I don't grasp them meaning of the "-F" option. My interpretation is as follows:

Given a filesystem w/ directories "/a/b" and "/a/c", and files
"/a/b/test.one" and "/a/b/test.two", then:

A) cd /a
fbackup ... -i b

should put b, b/test.one and b/test.two on the tape

B) using that tape, cd /a/c
frestore ... -i b -xvf ....

I *believe* will create in b in "/a/c" along with the files, the end result being "a/c/b" and files "a/c/b/test.one" and "/a/c/b/test.two".

C) remove "/a/c/b" and the files under it using "rm -rf /a/c/b"

D) cd /a/c and run
frestore ... -i b -xvF

will, I believe, restore test.one and test.two into /a/c (leading directory names discarded. You might need

frestore ... -i b/test.one -i b/test.two

========================================================
========================================================


Item 3:

You mentioned that the whole backup runs almost a full day.

Is there any reason why you don't test with some extremely small files? Run small test cases. It would seem to me that if you create those on the "client" and run the "fbackup / frecover" process on the NFS server, you will be testing the *process* which is what you appear to be having issues with. You don't even really need production servers. A test box, a few files, and a symlink so that the data is visible via two distinct paths should be enough for you to sort this out.

Once you get the test cases sorted, you should be able to apply that to the "real" jobs.

[skt_skt]

Absolute and reltive paths are causing the trouble as u said. Tried test fbackup && frecover both relative and absolute paths and worked.

[skt_skt]

thanks a lot