fbackup/frecover cannot access tape device

[Dag A.]

frecover displays the following error message:
"(5403) Unable to open or identify device at /dev/rmt/0m"

The same happens if I use other device files (e.g. frecover -f /dev/rmt/c0t3d0BEST -x -o -i/)

I have also tried to regenerate the device files using SAM, with the same result.

The tape drive is OK, and files can be written to/from tape using tar.

It is possible to run frecover remote on another machine with tape station
(link: http://www.webservertalk.com/archive292-2004-9-392429.html
"The problem is that fbackup/frecover tries to read first only a few bytes (1-10)
depending on the OS and fbackup/frecover version but the DLT's won't allow
this").

So this works:
frecover -f otherhost:/dev/rmt/0m -I
(reads the index from tape)

Usually the frecover is run from single user or run level 1. But to use the remote method, run level 2 or higher must be used, in order for the network to be available.
Does anyone know if this will cause problems with the restore, as more files/drivers are in use in run level 2?

Is it possible to avoid the problem with fbackup reading the initial bytes?

The tape station is HP DAT40 (DDS4)
Operating system is HP-UX 10.20

Best regards,

[Hasan Atasoy]

hi dag ;

which file are using in local for frecover. frecover needs /dev/rmt/0m for device file. so you should use that file.

Hasan.

[Dag A.]

These are the device files in /dev/rmt/

0x003000 0m
0x003080 0mb
0x003040 0mn
0x0030c0 0mnb
0x003000 c0t3d0BEST
0x003080 c0t3d0BESTb
0x003040 c0t3d0BESTn
0x0030c0 c0t3d0BESTnb
0xfffffe stape_config

frecover uses 0m as default, but I have also tried the other files (with -f option), with the same result ("unable to open or identify device at /dev/rmt/xxxx")

[Bill Hassell · Accepted solution]

The problem is that unlike primitive utilities like tar and cpio, fbackup talks to the tape drive in very specific ways which require knowledge of the drive. 10.20 is so old and has been unsupported for many years that fbackup doesn't know anything about a new DDS4 tape drive. The reason that it works for a remote tape drive is that the remote communication cannot talk to the hardware except for simple tape drive commands.

If the DDS4 drive was supported in 10.20, you'll need the last patch for 10.20. The patches were removed from the ITRC patch site a long time ago and the last location I could find with 10.20 patches was ftp://ftp.itrc.hp.com but it is no longer responding.

fbackup always reads the header on a tape to prevent overwriting a previous tape in a multi-tape backup. It is a requirement that you don't want to remove (even if it was possible). As mentioned in the link above, it is a hack to 'fool' fbackup into using unsupported tape drives. The DDS4 is very fast and using it over a remote connection slower than 1000Mbit will result in very, very slow operation (large number of restarts).

If you use the tape remotely, yes, you must have networking operational. However, fbackup cannot be used to restore the OS as it must be running in order to run fbackup. To restore the OS, you use make_tape_recovery to create a bootable tape. This tool will probably work OK with the DDS4 locally.

[whiteknight]

Dag,

10.20 has discontinued long time ago.. Found this docs, see if this help.

In various documents statements can be found that fbackup(1M) would be
currently unsupported for DDS4 drives with 10.20 (e.g. ER 8606165869
JAGad35160).

The problem is NOT related to fbackup(1M) itself. Actually a stape kernel
driver patch is needed to solve the problem:

PHKL_20528/PHKL_20529 or successors:
(SR: 8606125218 CR: JAGac40609)
No symptoms, enhancement request for DDS4
autoloader and standalone support.

To successfully work with DDS4 on 10.20 and fbackup(1M) the following patches
(or their successors) plus dependencies should be installed:

s800/10.20:
PHKL_22286 (stape), PHKL_22690 (scsi), PHCO_21263 (fbackup)

s700/10.20:
PHKL_22285 (stape), PHKL_22689 (scsi), PHCO_21263 (fbackup)

Hope this help

WK

[Bill Hassell]

Thanks whiteknight. I did some searching (with Mr. Google's help) and found this:

ftp://i3107ffs.external.hp.com/archived_patches/hp-ux_patches/10-800.html

For those of you that must remain on obsolete versions of HP-UX, I would strongly suggest bookmarking this ftp site:

ftp://i3107ffs.external.hp.com/

Then download all the patches for your old system(s) from archived_patches.

[Dag A.]

Thank you for your answers.
Sorry for the late update.
In the end, I went with the remote recovery option. It worked OK, but it creates a number of copies of files that are in use, e.g. "thisfile.1234".

I did not want to install new patches as I havent looked into possible conflicts with existing patches on the system being recovered.
However, I have previously backed up HP-UX 10.20 systems using DDS4 tape station without problems. I guess those systems had the patches you refer to.

[Dag A.]

Forgot to mention that HP-UX was installed first, before the recovery.

[Eric Jacklin]

Hi

You can try through SAM because SAM is also using fbackup in the background.

The only advantage if you run the recovey is in SAM it is manu driven so very less chance of missing something.

[Dag A.]

(See last entry 16.nov 2007)