I have some old SunOS tapes I need to look at the table of contents before I shred them.
Is there a Linux solution to restore these tapes?
migrated from stackoverflow.com Mar 5 '12 at 19:58
This question came from our site for professional and enthusiast programmers.
If the tapes are in tar format then you can try
If the files are in cpio format then
may work. If the tapes are in ufsdump format you can try using
then use ls and cd to look at what's on them
Assuming the tapes were written using tar,
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.
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
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...
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:
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:
Then you'll use dd to read a block from the tape:
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:
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.
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
Conveniently, file will correctly identify most tar, cpio, *dump data, compressed data, saving you from a long game of trial and error.
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.