[rescue] next up, how to read old tape of unknown format

[Mike Spooner]

There's also the I/O blocksize to worry about - may need to repeat the tape-file-format probe operations at a number of different I/O blocksizes. For instance, writing ufsdump with large tape-I/O blocksize (128KB or more) was often used to maximise throughput, although often it wasn't done like that for small backups. etc. etc.




-- Mike




On Fri, May 3, 2019 at 11:36 PM +0100, "Doug McIntyre" <merlyn at geeks.org> wrote:










On Fri, May 03, 2019 at 05:13:10PM -0400, Andrew K. Bressen wrote:
> Thanks for the SCSI disk reading suggestions! 
> 
> Next up, I have a pile of tapes (DDS/DAT) to read and a drive. 
> 
> I don't know the formats of the tapes... most are likely unix, but
> could be boot/install, dump, tar, possibly Legato Networker or 
> VMS BACKUP.
> 
> So, how do I read them and make sure I've gotten all of the data off?
> 
> And once the data is copied, is there a self-evident way to figure out
> what's a set of boot blocks and what's a tarfile, etc?
> 
> I have a 32-bit Linux box with a 3.x kernel running the tape drive. 


It'll be long work, because you won't know what you have.

First off, if you didn't know this, tape files are seperated by an EOF
marker (also called tape mark). When reading from the tape drive, you
will stop reading when you hit EOF. If you use the regular tape
device, your tape will rewind at this point, but there may be more
data on the next tape file (if that tape used that). If you use the
the non-rewind device, your tape head will still be at the EOF, and
you can try reading again to see if the next tape file holds data, or
if you hit EOF again. Two EOF's in a row should be EOT.  You can also
use the mt command to skip forward through tape files/marks. If you are
doing data recovery, there could be even data past EOT
(ie. overwritten tape), but you'd have to have special firmware to get
past an EOT to read it.

Now, it was totally up to the application that wrote the tape if they
even used multiple tape files. Many did not ie. tar a directory onto
the tape is one tape file. Some used many many of them. Typically for
ufsdump, you'd dump one partition, write a EOF no rewind, and then do
another ufsdump of another partition onto the next tape file.

Legato may use any number of tape files, depending totally on its own
internal scheme, so it can skip to the tape file that holds the data
you may be restoring. To do a full system disater recovery with
Legato, and it isn't a separate backup system, first you must go
through a painfully long catalog reconstruction with the Legato
software so it can build all the restore files it has into the
catalog, what is what in the tape files in the tape set you have, etc.

As to figuring out what you have... ufsdump and tar have unique
signatures that you can use the file command on your tape images. 
file may just figure out more for you as well.

I'd assume you'd find some sort of signature in the other formats,
they tended to have magic strings to look for as it was. But first I'd
see what you can read, and see what you might have.

NB: there is a tape archive format for SIMH, with some tools around it
to store tapes in a reasonable virtual file format.

I also kept this simplified for most common Unix formats.  There is
more to it than I outlayed here. If you do have VMS tapes, you may run
into those areas.
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue