frecover failure

[enrico.nic]

Hi,

I have an "old" HP rp3410 (RISC based) with HP-UX 11.31.

After a disk failure, I am trying to restore from backups on a different disk (and in a different directory). All backups have been done using fbackup on DDS tapes, and the restore operations went well with the first restore (a "level 0", full backup) and the second one (a "level 1" backup) directly from tapes. This means that the restored file system is now as it was on January, 23.

The disk crashed on January, 29 (last friday) and I wonder to restore also 4 backup that have been done at "level" 2, 3, 4 and 5. The last one (level 5) has been done on January, 29 in the early morning, so that in case of success of the complete restore operations I would lose only a few hours of work on that filesystem (the disk crashed in the early afternoon).

And here comes the problem I am encountering.

These last 4 backups have been done using fbackup, but afterwards the backup destination has been written (through a pipe) to tape using "dd" (dd of=<tape_device_file> bs=1024k). So backups are there, but written with "dd".

I extracted the four single files from the DDS tape to disk, through a "dd if=<tape_device_file> bs=1024k of=/dir/mybackupN" command, with success.

But when I try

# cd /newdir

# frecover -xvX -i /losed_dir -f - < /dir/mybackupN

or even

# cat /dir/mybackupN | frecover -xvX -i /losed_dir -f -

The result is always the same:

Bus error(coredump)

One strange thing that I've noticed is that if I try to restore the index of the backup file:

frecover -I /dir/index_bck -f - < /dir/mybackupN

I am obtaining a "Memory fault(coredump)" message, but an index file has been extracted from the backup file. My interpretation is that the file is in the right fbackup format and is Ok for frecover, but there must be reasons for which frecover can't read it.

Can anybody please help me ?

Thank you

Enrico

[Patrick Wallek]

I'm not sure why you're using redirects to read the file.  Just specify the name of the file in your fbackup command as part of the '-f' option.

# frecover -xvX -i /losed_dir -f /dir/mybackupN

[Dennis Handly]

In my previous experiences with round tapes decades ago, I found that if you didn't specify the right blocksize you would miss out on your data.  But that was with record oriented files and not byte stream.

When I use tusc(1) to see the block sizes using cat with a pipe to dd, I find it trying to read bs size chunks but the max size of a pipe is 8K.

So it reads 8K and writes 8K.  (I assume whether to a disk or tape it would work the same.)

For your case the proper way to write your tape should have been:

fbackup ... | dd of=<tape_device_file> ibs=8k obs=1024k

You should be able to read the tape with the 'proper" blocksize:

dd if=<tape_device_file> ibs=8k obs=1024k of=/dir/mybackupN

[enrico.nic]

# frecover -xvX -i /losed_dir -f /dir/mybackupN

With this command frecover tells me that /dir/mybackupN is not a device file. That's the reason for the redirection