If you need data recovered from old tapes, get in touch!
Backing up to tape
- Use
mbuffer
to buffer contents in RAM before writing to high-speed tape (such as LTO):
tar cvf - /dir1 /dir2 /dir3 | mbuffer -m 4G -L -P 80 > /dev/nst0
- Throw in compression into the mix:
tar cvf - /dir1 /dir2 /dir3 | lbzip2 | mbuffer -m 4G -L -P 80 > /dev/nst0
Dumping data from tapes
- Remember that block sizes written to tapes can be variable, so it’s usually good practice to set the driver to variable block length:
sudo mt -f /dev/nst0 setblk 0
- When dumping data from a tape, give
dd
a generous enough block size so that the largest block sizes can be accounted for:
sudo dd if=/dev/nst0 of=foo.bin conv=noerror,sync bs=64k
- If
dd
reports an error like “Cannot allocate memory” or even “Input/output error”, it usually means the block size is too small, or set to a fixed number instead of variable (0).
Working with the ftape driver
- Load the ftape driver when using a floppy (FDC) connected tape drive:
sudo modprobe zftape
- Dump data from ftape media:
sudo dd if=/dev/nqft0 of=data.bin conv=sync,noerror &
- Dump raw data from ftape media (for dumping everything including the tape header):
sudo dd if=/dev/rawqft0 of=data.bin bs=10240 conv=sync,noerror &
- Navigate back and forth between file records:
sudo mt -f /dev/nqft0 fsf 1
sudo mt -f /dev/nqft0 bsf 1
Specific software
QIC-40, QIC-80, QIC-3020, etc.
QIC-80 and QIC-40 tapes thankfully have a very well-documented format that was shared widely between various tools of the era. This format is part of my swiss army knife recovery tools. Another good way to read these tapes is using a parallel-port version of a Ditto-branded drive (which is compatible with Ditto tapes and QIC-80 tapes), and use the Ditto Tools software on a plain old Windows 98 laptop. (Ditto Tools is just a rebranded version of the old Colorado tools.)
TapeMate
Identified by the presence of the string !NSURE!
at the start of the first sector. This software has a proprietary format, but it helpfully has a driver that backs-up and restores from a DOS disk instead of tape. When configured to restore from a disk, it looks for a file called NSUREARC.FIL
in the root directory of the configured drive. This file has the same formatting as a tape dump, so you can use TapeMate in an emulator, with an emulated disk drive containing NSUREARC.FIL
as the tape dump. The dump file should consist of two file records: a 512-byte “header” record, and the next record containing the backup. But how is the tape “file marker” represented in the NSUREARC.FIL
dump, you ask? With a 512-byte “marker” sector in between records. The marker sector has the string FILEMARK
at the beginning, with all the other bytes set to 0xFF.
Novastor NovaNET 8.x
This software seems to use a proprietary compression format, so unfortunately the original software must be used to extract the files from the tape dumps. Here’s the rough workflow for recovering such data:
- Install the NovaNET 8.x software (evaluation version is fine), and edit the file called
NNCfg.Ini
. - Within the above file, there are configuration options for enabling backups to a disk drive. These lines are commented out by default. Uncomment them to enable backup/restore from disk, and set the
volumePath
to the drive letter where the backup will reside. (i.e. the drive where we will dump the backup to be restored.)
device=DiskDevice ; Enable these settings
[DiskDevice] ; to allow backup to
module=$prefix$$os$dsk.$ext$ ; media's other then [sic]
volumePath=g:\ ; tape drives.
-
Make a small sample backup using the software. This should generate files called
NN$DSKCT.DAT
andNN$DSKFL.000
. The .DAT file contains a small bit of metadata, and the .000 file is the actual backup contents. -
Dump the binary tape contents as usual. The block size should be 4K.
- Concatenate all the tape file records (there should be multiple) into a single file:
cat 0.bin 1.bin 2.bin ... > total.bin
- If the resulting single file is larger than 2 GB, split it up into exactly 2147450880-byte chunks:
split total.bin -b 2147450880
- Name these chunks
NN$DSKFL.000
,NN$DSKFL.001
, and so on. If there is only one chunk, leave it asNN$DSKFL.000
. - Move these files to the drive where the backup will be restored from (as configured above), to “replace” the sample backup that you made.
- Take the total size of the single binary file (i.e. before it was split up), and divide it by 4K, to get a count of 4K blocks comprising your entire archive.
- Hex-edit
NN$DSKCT.DAT
and poke in the total size of the large single file, as expressed in 4K blocks (not the total bytes!). The block count is a 32-bit little-endian number, and it appears in two locations: 0x10 and 0x28, both of which need to be modified:
54 57 44 4B 70 3A 46 67 74 03 F3 4B 00 10 00 00
B9 3F 04 00 BB 07 00 00 04 00 00 00 01 00 00 00
01 00 00 00 01 00 00 00 B9 3F 04 00 00 00 00 00
...
- In the above example, the encoded number is 0x43FB9. Update this number (in both locations) to represent the total 4K blocks in your archive.
- Once all of that is done, run the NovaNET software, go to “Devices” and right-click on “Disk device” and select “Import media”. This will import the catalog of the archive into the software’s database.
- Finally, go to “Restore”, and create a “restore job”. You will likely need to “move” the backup contents from the original nodes (original drives and systems) that you don’t have locally, to whatever drive and folder you’d like to recover into.
- Done! If you need to restore other backups after that, you’ll need to “clean up” inside NovaNET by deleting the backup job, deleting the “media” item you imported, and deleting any new “devices” that were imported into the “network” of devices in the program’s database.