Restore files on remote HP-UX Tape

[Greg Clark_2]

We have two HP-UX boxes. For simplicity I will call them UNIX1 and UNIX2. UNIX1 is HP-UX 11.0 and UNIX2 is HP-UX 11.31. I am trying to simply copy a set of files, that were backed up to tape, on the UNIX1 box to the UNIX2 box. The backup was made using sam.

UNIX1 really does not have enough space available to restore locally. Is there a simple way to rcp the files to the new HP-UX box? Currently I can rcp and have the necessary steps in place.

I know this is probably very easy but being new to UNIX I cannot find an easy method.

[Pete Randall]

Actually it is not very easy. HPUX does not handle remote tape drives well at all. Is there any chance you can switch the tape drive from UNIX2 to UNIX1 on a temporary basis?


Pete

[Greg Clark_2]

Unfortunately no. As we are moving to a blade enclosure. There are no scsi ports available.

[Pete Randall]

Then the most likely way I see to do this would be to back up and remove something from UNIX1 so that you will have enough space to recover your UNIX2 files. Then, after you copy them from UNIX1 to UNIX2, you can recover your temporarily displace UNIX1 files.


Pete

[Steven Schweda]

NFS?

> [...] using sam.

What, exactly, did SAM do? If it were "tar",
then something like this might work
(depending on how exactly how the tape was
created):

UNIX1# cd /net/UNIX2/wherever
UNIX1# tar xfo /dev/tape [...]

If fbackup/restore, then something similar?
The key (I claim) is to use NFS to access the
remote file system, and restore the files to
a different file system from the original
one. That can be more difficult if the tape
archive has absolute paths ("/xxx/yyy/...")
instead of relative paths ("xxx/yyy/...").

What, exactly, is on the tape?

[Patrick Wallek]

If it was done via SAM, it **probably** used fbackup. If that is the case, then you can do an 'frecover' and specify a remote tape device. However, if I recall correctly, it requires that remsh be enabled between the 2 hosts.

You should be able to peruse the frecover man page and see information about this.

[Steven Schweda]

> The key [...]

More accurately: _A_ key [...]. Using either
a remote file system (like NFS) with a local
tape device, or a local file system with a
remote tape device, should be possible (if
the appropriate back-up program can deal with
the particular remote gizmo, and the rest of
the required infrastructure is in place).

[SoorajCleris]

Hi,

I would suggest you to go for NFS;
that is a good idea.

Regards,
Sooraj

[Steven E. Protter]

Shalom,

There is no facility in the OS for this type of tape sharing.

You would need to copy the file to the system with the tape and then with a remote session on that system write to the tape.

SEP

[Steven Schweda]

> There is no facility in the OS for this
> type of tape sharing.

If true, then that would seem to make HP-UX
almost uniquely lame among UNIX
implementations.

man rmt

I never use it, but it seems to be there.
("man rdump", too, for example. I believe
that some flavors of "tar" can do this, too.)

Operating a local tape drive with a remote
disk (file system) always seemed to me to be
less trouble than the other way around.
Especially if "remote" means so remote that
you can't see the flashing lights (or hear
the whirring sounds) of the actual tape
drive.

[Patrick Wallek]

>>There is no facility in the OS for this type of tape sharing.

NOT TRUE!

See the '-f' section of the frecover (or fbackup) man page:

â f device
device identifies the backup device to be used instead of the default /dev/rmt/0m. If device is â , frecover reads from standard input. Thus fbackup and frecover can be used in a pipeline to backup and recover a file system as follows:

fbackup â i /usr â f â | (cd /mnt; frecover â Xrf â )

If more than one output file is specified, frecover uses each one successively and then repeats in a cyclical pattern. Patterns can be used in the device name in a way similar to file name expansion as done by sh(1). The expansion of the pattern results in all matching names being in the list of devices used. A device on the remote machine can be specified in the form machine:device. frecover creates a server process, /usr/sbin/rmt, on the remote machine to access the tape device. If /usr/sbin/rmt does not exist on the remote system, frecover creates a server process from /etc/rmt on the remote machine to access the tape device. The pattern matching capability does not apply to remote devices.
Only raw magnetic tapes can be remote devices. The fast search marks capability is not used when accessing remote DDS devices.

Note the sentence: "A device on the remote machine can be specified in the form machine:device."

[Bill Hassell]

fbackup/frecover can use a remote tape. You will be experimenting with 11.0 versus 11.31. Many incompatible changes were written into fbackup/frecover for 11.31 such that tapes on 11.31 are not backward compatible with previous HP-UX versions. Whether these changes affect 11.0 to 11.31 frecover has never been documented. Let us know what you discover.

[Steven Schweda]

> [...] Whether these changes affect 11.0 to
> 11.31 frecover has never been documented.
> [...]

Any backup software where a new version
couldn't read an old tape would lead me to
seek a different vendor very promptly.

[Bill Hassell]

> Any backup software where a new version
> couldn't read an old tape would lead me to
> seek a different vendor very promptly.

Actually, HP solved the problem by deprecating fbackup for 11.31 -- which means that it is gone for the next rev...

[Steven Schweda]

> Actually, HP solved the problem by
> deprecating fbackup for 11.31 -- which
> means that it is gone for the next rev...

Removing fbackup is one thing. Removing
frecover is another.

(When BACKUP disappears from VMS, it'll be
time to throw in the towel.)

[Dennis Handly]

>Steven: Any backup software where a new version couldn't read an old tape

This direction for frecover should be supported.

[Sagar Sirdesai]

How about using NFS mount on UNIX1 from UNIX2 and start the restore.

Sagar

[Steven Schweda]

> How about using NFS [...]

Whoa. Why didn't I think of that? No, wait,
...