8mm Exabyte backup tapes written between 1994 and 2003 were created with the ufsdump command on a Solaris box. We no longer have the Solaris box, but the Exabyte tape drives are now hooked up to algol (running linux) and can be used to recover the files using restore, the linux port of ufsrestore.
Unlike ufsrestore, restore requires you to specify the blocking factor used to write the files to tape. And, since the dump scripts wrote multiple file partitions to each tape, you also need to tell restore which tape file the partition was written to on the tape. Both the blocking factor and tape file index can be determined by inspecting the the old dump logs stored on algol under /docs/thuban-docs/dumps/
Example:
Joel hands you an Exabyte tape with the label “2/9/95” on it, and asks you to recover a file from the “/usr3” partition that was written to that tape.
1. Login to algol as root
2. cd /docs/thuban-docs/dumps/1995/
3. View the dump log for that date (e.g. ./02.09.95.dmp.gz) using emacs or less (which run gunzip on the fly), and look for ‘/usr3’.
4. Determine the blocking factor used for that tape. Look for a line like: “DUMP: Writing 32 Kilobyte records“, and remember that value (’32 Kilobyte’ in this case). Note that historically the blocking factor changed over time, so always check the blocking factor used for the particular dump in question.
BLOCKING FACTOR = 32KB
UPDATE 2015-06-17: Older tapes (for which there are no dump logs) often used a blocking factor of 10KB.
UPDATE 2015-06-17: If you don’t know the block size, use the commands “mt -f /dev/st0 setblk 0; mt -f /dev/st0 setdensity 0x0” to set the drive to “variable mode”. This gives you lower performance (only 1 block is transferred for each SCSI command, plus Check Condition overhead). If you do this, don’t specify the -b <blocksize> argument when using the restore command.
5. Now determine the index of the tape file the partition you want to recover. Starting at the top of the dump log file, counting from ‘1’, count the number of “DUMP: DUMP IS DONE” lines until you get to the “DUMP: DUMP IS DONE” line for your partition.
In this dump log, partition ‘/usr3’ was written as the 16th tape file to the tape, so:
TAPE FILE INDEX = 16
6. Insert the tape in the Exabyte tape drive
7. Rewind the tape. Currently the Exabyte tape drive is /dev/st0, so issue this command:
mt -f /dev/st0 rewind
8. Tell linux what the tape density is using ‘mt‘. Linux seems to autodetect this, but just to be safe… :
mt -f /dev/st0 setdensity 0x15
If you don’t know the tape density, you can set the density to 0 instead:
mt -f /dev/st0 setdensity 0
9. Tell linux which blocksize to use with ‘mt’. In this case our BLOCKING FACTOR is 32kb, which the ‘mt’ command likes to get as an actual byte count. So we multiply 32 x 1024 to get 32768.
mt -f /dev/st0 setblk 32768
If you don’t know the blocksize, set it to 0 (and don’t specify the -b <blocksize> argument to restore:
mt -f /dev/st0 setblk 0
10. cd to the directory you want to put the recovered files in.
cd /tmp/recovery/1995-02-09
11. Call the ‘restore’ command with the following syntax:
restore -a -i -v -b <blocksize> -s <tape file index> -f /dev/st<tape drive ID>
The above arguments tell ‘restore‘ that we want to recover files in interactive mode (-i), ignore volumes (-a), and run in verbose mode (-v).
Given our BLOCKING FACTOR of 32kb and TAPE FILE INDEX of 16, we issue this command:
restore -a -i -v -b 32 -s 16 -f /dev/st0
‘restore‘ should now forward the tape to the 16th tape file and then enter interactive mode, which is somewhat ftp-ish.
Once in interactive mode you can use ‘cd‘ and ‘ls‘ to explore the partition. You can specify the files to extract by issuing the ‘add <fname>‘ command. When <fname> is a directory ‘add‘ recursively targets the directory and it’s contents. The ‘ls‘ command prefixes the names of files ‘add‘ed to the extraction list with an ‘*’.
For a full list of commands use the ‘help‘ command.
Once you’ve told ‘recover‘ which files to recover to your local directory with ‘add‘ commands, issue the ‘extract‘ command to initiate the recovery. This can take several minutes, up to an hour in some cases, so go do something else and come back later.
When ‘recover‘ has recovered the files it will ask you:
set owner/mode for '.'? [yn]
Answer ‘n‘.
Here’s a sample interactive recovery session. In this case we restore the directory ‘./applications/p1391/’ from the ‘/usr3’ partition saved to the ‘2/9/95’ dump tape:
[root@algol /tmp/recovery/1995-02-09]$ restore -a -i -v -b 32 -s 16 -f /dev/st0
restore > ls
.:
11.29.dmp applications/ old_lang/ spool/
aipsnewest/ lang/ software/ tmp/
restore > cd applications/
restore > ls
./applications:
book/ games/ hiabs/ psrcat/ tempo/
ftptool/ graphing/ p1391/ starlink/ timing/
restore > add p1391
restore > extract
… [WAIT UP TO AN HOUR] …
set owner/mode for '.'? [yn] n
restore > quit
[root@algol /tmp/recovery/1995-02-09]$
Kudos to James Fuller for figuring this out.