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.
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.
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.