Stefan's Blog



2023-09-27

Restoring (NT)Backups From a SCSI Tape Drive

A stack of tapes is stapled on my desk. Alongside these tapes is a drive standing there, left over from another age of computing. A hefty brick, heavy and clunky. Turning it on reminds me how noisy computing once was.

Taking a closer look provides the vendor and type, an HP Surestore DAT40. Of course, I want to take a look at the tapes. After installing a leftover SCSI card and connecting the drive the goal is to find out how to read and restore the unknown content the tapes provide.

A Surestore DAT40 Tape Drive standing on a table

Read From a Streaming Device


Listing SCSI devices shows that the HP DAT 40 is recognized as a streaming device.

After the drive is connected there are at least two streaming devices in /dev, which are /dev/st0 and /dev/nst0. The former rewinds automatically after reading, the latter stays on the block which was read.

lsscsi
[1:0:0:0]    disk    ATA      ST1000DM003-1SB1 CC43  /dev/sda
[5:0:0:0]    disk    ATA      KINGSTON SA400S3 B1D1  /dev/sdb
[6:0:5:0]    tape    HP       C5683A           C305  /dev/st0
[N:0:0:1]    disk    CT1000P1SSD8__1                            /dev/nvme0n1

Initially, I checked if the data could be extracted by the tar tool, but it was impossible to do so. The tape archive tool recognizes that the tape was not stored using tar, so the mystery continues. I have to try some other utilities, the cat doesn't cut it.

cat /dev/st0 > backup.iso
cat backup.iso
TAPE
    xZ)2^
         B�Band erstellt am 26/10/00Microsoft Windows NT Backup (NTBACKUP.EXE) Version 1.0 Rev. 3.41%

Reading from /dev/st0 provides the following output. Both tools, dd as well as cat stop reading after the first null byte. That means storing the tape can not be done in one single file.

dd if=/dev/st0 of=./extracted_backup ibs=256k count=1
0+1 records in
32+0 records out
16384 bytes (16 kB, 16 KiB) copied, 0,411593 s, 39,8 kB/s
cat ./extracted_backup
TAPE0;S+L^
          G(PMedium am 20.12.2001 um 10:27 erstelltMTF Media Label|1.0|Seagate|NTBackup5.0|2001/12/20.09:29:16|Seagate 2001/12/20.09:29:16|1|{CDD225CA-6A4F-44AB-A1FB-C2507BDB6EB0}||Microsoft Windows NT Backup (NTBACKUP.EXE) Version 1.0 Rev. 3.41SPAD=)%                                                               

A look at the output shows the tape contains an NTBackup. What is that, you might ask? At least I did. It is a proprietary protocol from, you guessed it, Microsoft. NTBackup.exe uses the Microsoft Tape Format (MTF) to put the data on tape. The resulting backup file has a file suffix of *.bkf, which is recognized by NTBackup.exe if all goes well and no bits are flipped.

I am intrigued, why am I not able to just read the data from the tape into a single file and extract the content? In order to process the backup data I have to find out some details about the status of the tape.

Tape Status


To gain some insights about the status of the tape I installed mt-st.

yay -Ss mt-st
aur/mt-st-git 1.4.r10.gfbfd923-1 (+7 0.00)
    Utilities for managing magnetic tape storage devices

The status command provides information about the tape inserted. When using tar to write the tape there usually is a block size in bytes, but not when using ntbackup. The block size is 0 bytes.

mt-st -f /dev/st0 status

SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x13 (DDS (61000 bpi)).
Soft error count since last status=0
General status bits on (45010000):
 BOT WR_PROT ONLINE IM_REP_EN

To simply check at which block the tape is currently I use the following command

mt-st -f /dev/st0 tell
At block 0.

The last line displays the status information about the tape. Following the indicators, it is positioned at the beginning, it is write protected and ready to operate.

Status Bit Description
BOT The tape is positioned at the beginning of the first file.
WR_PROT The tape (or drive) is write-protected. For some drives this can also mean that the drive does not support writing on the current medium type.
ONLINE The drive has a tape in place and ready for operation.
IM_REP_EN Immediate report mode. This bit is set if there are no guarantees that the data has been physically written to the tape when the write call returns. It is set to zero only when the driver does not buffer data and the drive is set not to buffer data.

It is all well and good but it does not solve the issue the sudden stop while reading the data.

Preparing for Backup Extraction


A shell script is needed to extract multiple parts and concatenate the resulting file. I found one at 108.bz that I modified. Now all extracted parts are merged into a single file. Here is the content of the script:

#!/usr/bin/env bash

for f in {1..20}
do
    dd if=/dev/nst0 of=tapeblock"$(printf "%06g" "$f").bin" ibs=16384
done

cat tapeblock* > "$(date +%F)"_"$(date +%T)"_tape_backup.bkf

It is time to make a coffee and to run the script in the meantime.

./read_blocks.sh
1+0 records in
32+0 records out
16384 bytes (16 kB, 16 KiB) copied, 0,00643381 s, 2,5 MB/s
112576+0 records in
3602432+0 records out
1844445184 bytes (1,8 GB, 1,7 GiB) copied, 405,47 s, 4,5 MB/s
90+0 records in
2880+0 records out
1474560 bytes (1,5 MB, 1,4 MiB) copied, 0,258718 s, 5,7 MB/s
148188+0 records in
4742016+0 records out
2427912192 bytes (2,4 GB, 2,3 GiB) copied, 516,446 s, 4,7 MB/s
177+0 records in
5664+0 records out
2899968 bytes (2,9 MB, 2,8 MiB) copied, 0,409002 s, 7,1 MB/s
0+0 records in
0+0 records out
0 bytes copied, 0,0042947 s, 0,0 kB/s
dd: error reading '/dev/nst0': Input/output error
[...]
0+0 records in
0+0 records out
0 bytes copied, 0,000293704 s, 0,0 kB/s

There is a clear indication that this has been somewhat successfully read using mt-st, or at least the reading time was higher than just using dd or cat without the loop. The position of the block afterwards shows a positive result, too. That means progress.

mt-st -f /dev/nst0 tell
At block 261032.

I do a rewind of the tape and eject it.

mt-st -f /dev/nst0 rewind

mt-st -f /dev/nst0 tell

At block 0.

mt-st -f /dev/nst0 eject

Extracting the NTBackup5 MTF Stream


At first, I tried to extract the files through the NTbackup tool inside a Windows 2000 VM directly, but it did not recognize the *.bkf file correctly. Maybe it was the wrong version of ntbackup and/or Windows, who knows. I did a web search to find another approach to the challenge.

NTBackup.exe on Windows 2000

I found mtftar. This tool translates the NTbackup file stream so that it can be read by tar.

mtftar is a tool for translating a MTF stream to a TAR stream.

mtftar < Vollsicherung_20_12_01.bkf | tar xvf -

[..]
C:/Inetpub/Mailroot
C:/Inetpub/Mailroot/Badmail
C:/Inetpub/Mailroot/Drop
C:/Inetpub/Mailroot/Mailbox
C:/Inetpub/Mailroot/Pickup
C:/Inetpub/Mailroot/Queue
C:/Inetpub/Mailroot/Route
C:/Inetpub/Mailroot/SortTemp
C:/Inetpub/scripts
C:/Inetpub/wwwroot
C:/Inetpub/wwwroot/default.asp
C:/Inetpub/wwwroot/postinfo.html
C:/Inetpub/wwwroot/_vti_inf.html
[..]
C:/jdk1.1.8/demo/SimpleGraph
C:/jdk1.1.8/demo/SimpleGraph/example1.html
C:/jdk1.1.8/demo/SimpleGraph/GraphApplet.class
C:/jdk1.1.8/demo/SimpleGraph/GraphApplet.java
C:/jdk1.1.8/demo/SortDemo
C:/jdk1.1.8/demo/SpreadSheet
C:/jdk1.1.8/demo/SpreadSheet/Cell.class
C:/jdk1.1.8/demo/SpreadSheet/CellUpdater.class
C:/jdk1.1.8/demo/SpreadSheet/SpreadSheet.java
C:/jdk1.1.8/demo/SpreadSheet/SpreadSheetInput.class
C:/jdk1.1.8/demo/TicTacToe
C:/jdk1.1.8/demo/TicTacToe/example1.html
C:/jdk1.1.8/demo/TicTacToe/TicTacToe.class
C:/jdk1.1.8/demo/TicTacToe/TicTacToe.java
C:/jdk1.1.8/demo/TicTacToe/audio
C:/jdk1.1.8/demo/TicTacToe/audio/beep.au
C:/jdk1.1.8/demo/TicTacToe/audio/ding.au
C:/jdk1.1.8/demo/TicTacToe/audio/return.au
C:/jdk1.1.8/demo/TicTacToe/audio/yahoo1.au
C:/jdk1.1.8/demo/TicTacToe/audio/yahoo2.au
C:/jdk1.1.8/demo/TicTacToe/images
[..]

And there it is. The verbose output shows a lot of extracted files. Let's take a look at the version of Windows this backup contains.

cat backup/C:/WINNT/system32/eula.txt

************************************************************************

Microsoft Windows 2000 Professional    Lizenzierte Kopien: 1

************************************************************************
ENDBENUTZER-LIZENZVERTRAG
************************************************************************

This took me longer than expected. Interacting with the tape is pretty straightforward on a Linux machine and the mt-st command. The nature of a tape drive was somewhat clear to me – you stream the data from beginning to end – but not how to handle the data on tape. The block size of 0 in combination with stopping the tape read process after every null byte was an interesting fact to learn.