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:

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.

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 berlios, 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...

Assuming the tapes were written using tar, tar -tvf your-backup-file.tar will print out a list of files and directories in the archive without extracting them. This still involves reading the entire archive off the tape so it will take a long time.

You may need to install drivers for your particular tape drive. It might help if you update your question with the brand and model of your tape drive. The software used to make the backup may help too if you know that.

He said they were tapes. So -f needs to point to the tape device, not a .tar file.
–
jftugaMar 21 '12 at 14:12

Indeed, but since I don't know what device his tape drive will be, your-backup-file.tar is a placeholder that he will need to change to whatever is appropriate. The point of the answer was the -t option which allows him to list the contents of the archive without unpacking the whole thing.
–
LadadadadaMar 21 '12 at 15:06

handling a tape drive is quite different from extracting files. The magic isn't in the "t" flag, but rather in knowing at which point of the tape the current reading process is starting. It doesn't help to use a non-rewinding device to skip to the desired file, if the tar used afterwards uses the rewinding device, thus leaving the tape at 0 after reading.
–
Tatjana HeuserMar 29 '12 at 12:17

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.