Can't recover most of /var

[Alex Georgiev_1]

Well, I think I'm screwed. I have a backup tape that either went bad, or just plain doesn't have the files that I need on it. After replacing a non-root drive on a G70 system with HP-UX 11.0 I had to recover the /var dir, which had been sitting on the old drive.

I started the recovery and part way through it I got:

frecover(5401): Volume 1 completed.
frecover(5404): Press return when the next volume is ready on /dev/rmt/0m:

frecover(5423): incorrect volume mounted;
frecover(5424): expected volume 2, and got 1
frecover(5433): Do you wish to continue using this volume? (^[yY]/^[nN]) n
frecover(5412): Do you wish to try to salvage this volume? (^[yY]/^[nN]) y
frecover(5413): attempting to read backup following bad volume header
frecover(1001): file trailer does not match file header for
frecover(1002): file /var/adm/sw/save/PHCO_17712/TEXT-FMT/usr/bin/nroff
frecover(1045): error in trailer recovery

My attempts to salvage the volume failed. I used the -S option of frecover, and you are seeing the results above. I tested the drive and it's working fine! For some reason or another frecover thinks that there should be a 2nd volume, even though fbackup finished fine on this single tape. In fact, all files in /var are listed in the index, when I retrieve it with the -I option. Yet, frecover seems to believe that they are not there. And since this is not an I/O error, then most likely they really arn't there. Sigh!

So, now I have three options, and my question is, which one is my best bet:

1. I asked the HP guy who replaced the drive to let me keep the old one. He refused, but said that he will keep it for a day or two. Option one is to ask him to bring it back, hoping that he was true to his word.

2. I have a boot tape containing the volume group that this drive was part of. The boot tape is very recent, and I can restore the entire machine from there... Is it worth doing this? Is there a way to get just the /var dir out of the boot tape? I tried using 'tar xvf /dev/rmt/0m /var' with the boot tape, with no success. I think it may have to be done file by file, which would take longer than restore the entire machine...

3. Re-create the /var structure by hand, and kiss the old log files goodbye? I have most of /var/adm, with exception of syslog/ utmp/wtmp files. However, I don't have anything else in /var, other then the adm/ dir.

Well, any advice from experienced admins on how to save my behind?

[Michael Tully]

Hi,

If the boot tape your referring to is an ignite tape, then there is some hope.

You could try this:

# mt -t /dev/rmt/0m rew
# mt -t /dev/rmt/0m fsf 1
# tar tvf /dev/rmt/0m
if the files are listed, then try again this time extracting the files.

# mt -t /dev/rmt/0m rew
# mt -t /dev/rmt/fsf 1
# tar xvf /dev/rmt/0mn var/

good luck
Michael

[Alex Georgiev_1]

Well, this just keeps getting better and better...

'tar tvf' lists the files I need, but 'tar xvf' says:

Tar: blocksize = 4
directory checksum error

Does this mean my boot tape went bad? Or am I going to have to set the block size with the 'b' option? If so, what is the blocksize that Ignite uses?

[Pete Randall]

Alex,

Did you do the 'rew' and 'fsf' before your 'tar -xvf'?

Pete

[Alex Georgiev_1]

Yes, I did the rewind and the forward 1 file. It turns out I lied about the files being listed, though. They are NOT LISTED when I run 'tar tvf /dev/rmt/0mn'.

Fortunately the drive is on it's way back, so I should be able to get the files off of it. If not, that leaves me only two options: re-install, or recreate the most important files and directories in /var by hand.

[Pete Randall]

Well, for what it's worth, Alex - I'd go for a re-install. Look on it as an opportunity to clean things up, re-size file systems, apply the latest patches to the latest OS. In other words, try to see the bright side.

Pete

[Frank Slootweg · Accepted solution]

Going back to the frecover problem:

Very, very likely your fbackup went wrong because it needed an extra tape. This is probably a SAM Scheduled Backup. If so, you should have gotten e-mail to root and that e-mail probably said that things went wrong. The common problem is that people do not expect this e-mail or do not read it.

As to the needed files being in the *tape* index: They always are. The *tape* index is not to be trusted (except on the *last* *non-full* tape), because the index is at the beginning and fbackup can not know at that time if the backup will succeed or not. See the fbackup manual page for details (just search for "index").

Only the on-*disk* index made by *fbackup* (*not* frecover) is to be trusted. Perhaps there is still a valid one in /var/sam/log/br_index*. Note that the second field of a backed up file/directory must be "1".

If, after the fact, you want to know what *is* on the tape, you can do a pseudo ("N") restore in verbose ("v") mode and log the list of files:

/usr/sbin/frecover -r[m]vN -f /dev/rmt/... 2>/tmp/filelist

I hope this helps to prevent future problems.