This article will show you how to handle tape backups generated by NTBackup, turn them into a .BKF file (using Linux) and extract specific files (using Linux/Windows). Some of the stuff explained here may also be useful when dealing with corrupt tapes/files, and may work for any backup software that generates MTF (Microsoft Tape Format) output, such as maybe Symantec Backup Exec¹.

The scenario: an old machine (hosting a not so important app) crashes badly due to multiple disk failures. O.S. (Windows 2000 Server) won’t boot anymore. Backups were directed to a local DDS tape drive, the only one of its kind surviving in the whole Company. While reinstalling the app to another server, I need to recover some files and have access to the pre-crash registry.

And here’s the plan:

• Boot the half-dead server with the invaluable SystemRescueCd.
• Put the last available tape backup in the drive.
• Save an image of the tape somewhere.
• Extract stuff from the image.

When SystemRescueCd is running and network connected, make available a shared folder:

Then, generate the image. NTBackup tape backups are spread across multiple “tape files”. If you read the tape from the beginning, sooner or later you will hit EOF (an end-of-file condition). Don’t rewind it: go on to the next file instead. Repeat until there are no more files to read.
On Unix, the first SCSI tape device is mapped to /dev/st0 and /dev/nst0. When a process finishes reading from /dev/st0, the tape is implicitly rewound. Viceversa, using /dev/nst0 doesn’t cause any rewind; tape will stay positioned right after the last block read.

Just in case, perform a manual rewind:

Then, try to guess the right block size. It seems to be set at 16K. Should this method fail, check the “How do I find out tape block size?” method here.

Start reading (by means of dd) with the specified block size. See? We’re using the non-rewinding tape device /dev/nst0.

Reads beyond the last file will result in an “Input/output error”.

It’s time to join the .bin files into a single one: the tape image (maybe using HJSplit for the task). You could’ve been more clever than me and appended dd‘s output to a single file, thus skipping the join step and saving space. I didn’t do it because I wanted to see if any tape file was corrupted (and be able to re-read it, if needed).

I called the tape image “backup.bkf”, even though it’s not a true .BKF file… As we said, it’s a tape image. NTBackup is not able to read it, whereas the abundance of “BKF recovery” software can. Before going on, let me polemicize a bit. There are many, almost identical, software of this kind. I’ve got the feeling that they all “borrow” from this open source BKF reader². Looks like different commercial developers grabbed the same source, embellished the GUI just a bit, and made a product to sell. How lame. But it turns out that you don’t need to pay a cent to extract files from a .BKF or tape image, on Linux or Windows as well.

On windows, get ntbkup by William T. Kranz . I use the (optional) -s3 switch to target set 3 which I know holds the System State.

Bingo, I can load the software hive with “reg load” (see here) and extract the keys I need.

Should you prefer so, download mtftar on your Linux box, compile it and run something like:

Extract the other files you need and voilà…