tape-to-tape copy, different machines

[Michael D. Zorn]

We have an old HP-UX 10.01 machine with a DDS-2 drive, and a new HP-UX 11i machine with a DAT-72 that handles DDS-3 tapes. There are a set of old-machine archival backup tapes (from 'fbackup') that we'd like to keep "just in case". Naturally, the DAT-72 won't read DDS-2 tapes. Is there a way to copy directly across the two machines?

dd doesn't recognize "of=otherMachine:/dev/rmt/0m".
rcp doesn't seem to like "thisMachine:/dev/rmt/0m" as an arg.
cpio seems to want to look at headers.

[A. Clay Stephenson · Accepted solution]

If this were cpio or tar then it would be easy but fbackup (while it does allow remote tape devices) uses variable blocking and therefore dd through a remsh pipeline will not work. In fact, duplicating an fbackup tape on the same machine would prove to be a very difficult task.

About your least evil and most reliable approach would be to restore the data using frecover and then fbackup to the newer tape drive. Of course, if your backups used /absolute paths then that is fraught with peril as well altough a chroot'ed restore would prevent you from cvlobbering an otherwise perfectly good system.

[Geoff Wild]

How about a pipe?

dd if=/dev/rmt/0m | remsh otherMachine 'dd of=/dev/rmt/0m'

I think you can do that with frestore | fbackup as well...

Rgds...Geoff

[A. Clay Stephenson]

Dd, even on a local machine, will not duplicate fbackup media. The format is simply too complex.

[Michael D. Zorn]

Quick question for Clay: doesn't dd just copy bytes?

I just remembered a program I wrote last year to copy 9-track tapes to disk. Disk files don't know about record lengths, but tapes insist on them. I might be able to use that method (and I probably wouldn't have thought of it till I read your responses. (After all, 9-tracks are round, and my program is a round-tape copier. (I copy the tape data to disk, along with a file of record lengths. On the output side, I write to the tape using those record lengths.)

I think the variable reord-length thing might make even the remsh suggestion unworkable.

I'll add to this thread again later as I exhaust more options....

[A. Clay Stephenson]

If you are under a service contract then you have full access to the Technical Knowledge Base. This paper explain the fbackup format:

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000064722384

[Dennis Handly]

>I just remembered a program I wrote last year to copy 9-track tapes to disk.

Yes, it seems that's all you need to do, and if square tapes still have EOF marks, you need to remember them too.

>I copy the tape data to disk, along with a file of record lengths.

Any reason you didn't just intersperse the record lengths in the file, like typical variable length record formats?

[Steve Lewis]

What about an NFS mount? Did we have NFS in 10.01? I can't clearly remember back that far!
i.e create a directory on your new 11i server and NFS export it back to the old 10.01 box. On the old box mount the NFS dir, cd to it and frecover with a -X to dump the contents local to the current directory.

[Steve Lewis]

- otherwise just use the remote tape drive spec in frecover:
... -f oldbox:/dev/rmt/0m ... to dump the tape to a local dir, then re-backup, like what was said above.
Its a good idea to migrate your old tape data to new media, because I have noticed that old DDS tapes get sticky and unreliable if not periodically aired with a wind-through, but if you wind them too often they get worn out anyway so you can't win with an old tape.

[Peter Nikitka]

Hi,

AFAIK, a DAT72 Drive can at least READ a DDS2 (=120m) tapes: did you really verify, that e.g. the index of your fbackup DAT cannot be read from your new DAT drive?

NTHL, it is a good idea to 'refresh' the old backup tapes, like Steve suggested!
If the tapes are readable, you can da a local restore + backup to new tapes.

But why do you use no DDS4 or DAT72 DATs? You had a higher compatibility for future devices, compared to DDS3: A - really old - 60m-DDS cannot be written in a DDS4 drive, today.

mfG Peter