Restore old SunOS tapes

If the tapes are in tar format then you can try

tar -tf /dev/sr0

If the files are in cpio format then

cpio -ivtB </dev/sr0

may work. If the tapes are in ufsdump format you can try using restore

restore -if /dev/st0

then use ls and cd to look at what's on them

Iain gave a part of the answer, but it isn't complete. Here comes advice on how to read unknown tapes on a linux host:

Blocking factor

You need to know what blocking factor has been used, unless the (possibly ancient) drive uses a fixed block size. First, you'll have to set the drive to use soft blocking factor:

# mt -f /dev/nst0 setblk 0

Then you'll use dd to read a block from the tape:

dd if=/dev/nst0 of=./testfile bs=128k count=1

You may need to try several block sizes, preferably something big enough. If the selected dd block size is bigger than the actual tape block size, dd will only read one block, something like this:

# dd if=/dev/nst0 of=./testfile bs=128k count=1
1+0 records read
1+0 records written
32768 bytes (32 kiB) copied, 236 kiB/s

Here we've discovered that a 32K block size was used, that's the first important information. Note: if you're using too big a block size, various weird errors may occur, like an IO error. Most old tape drives won't accept reading much more than 128K at a time, maybe less for ancient formats like QIC.

Data format

Now that you've determined tape block size, it's time to find out what's the tape data format like! Here we should use a precious and powerful tool: the file command. Now we should grab some more blocks from the tape to determine what it is more easily:

# dd if=/dev/nst0 of=./testtape.img bs=32k count=100
100+0 records read
100+0 records written
3276800 bytes (3 MiB) copied, 160 kiB/s
# file ./testtape.img
testtape.img: POSIX tar archive (GNU)

Conveniently, file will correctly identify most tar, cpio, *dump data, compressed data, saving you from a long game of trial and error.

Caveat

Tapes may very well host several different data formats. A common occurrence for tapes using an index-less format (like tar) is to have a text file listing the tape content as the first file, for instance, or some other similar headers. So you may need to read several records before finding actual data.

This turned out to be the tapes were written with a unique version of CPIO which existed only on early versions of SunOS, I'm guessing SunOS 2 or 3. At the time, in the early 90's ( when I was a cowboy, not a sysadmin), Auspex (SunOS) was a major play in UNIX file servers. Sun was trying to enable large files (> 2GB, aka BIG_FILE). The nuts & bolts of CPIO is that the first field of X bits in a CPIO dump record is the byte count in that INODE. This is all good and fine. Except that later CPIO was standardized in a different number of bytes to represent the byte count of the INODE.

You can imagine the fun that ensues when your filename is preceded by random bits, and your byte count is wrong.

Do you mean SunOS System tapes, or tapes written on an old SunOS System? The system tapes start with a boot image, followed by a table of contents (to be read with /usr/etc/install/xdrtoc), followed by the individual packages in tar.gz format as laid out by the TOC file. You need to skip to the file you want to extract using mt (for example. mt -f/dev/non-rewinding-tapedevice fsf to skip to the next file)

If you want to read tapes written on old SunOS Systems, I'd use star, downloadable from sourceforge, since it is able to read more or less any tar format (including historic versions), pax or cpio.

For ufsdump format, the usage of ufsrestore has been pointed out by a previous poster.

Tip: nowadays, the contents of these old tapes most likely squeeze easily into a filesystem available. To reduce wear on the worn old tape, it may be a good idea to loop over the tape, reading one file after the other into files for further exploring. Just remember to always use the non-rewinding tape device (such as nrst0, or whatever tape device points to your drive), for every once you happen to forget that tiny detail, you start at 0.

In the past, this has led to many unpleasant situations, such as backups overwriting their predecessor again and again on that magical never-filling tape, or restores which would only find part of the data, when everyone was sure that there should be several archives on the tape...

(links updated 2019-06-17)