Festplatten sichern mit BasicLinux (Hands-on)

📅 Erstellt: 20.08.2026 🔄 Aktualisiert: 24.08.2026

Ich beschreibe hier eine Sicherung einer ATA1-Platte, 102 MB, noch mit C/H/S angegeben aus einem Highscreen Kompakt Serie III 386SX-25 Rechner. Dort sind noch Central Point Software Programme, diverse Highscreen/Vobis eigene Programme drauf, die ich zur "Preservation" gerne sichern möchte bevor ich damit weiter rumgurke.

Da mein Ugreen USB -> IDE Adapter erst ab ATA-2/LBA-Standard mit Festplatten klarkommt kann ich am modernen PC nicht auf die alte IDE-Festplatte zugreifen und sie nicht direkt sichern.

Die besagte ATA1-Platte habe ich also einfach mal in meinen IBM Aptiva 486 gesteckt, am CD-ROM IDE Kabel anstatt angeschlossen. Das proprietäre BIOS des 486 konnte damit nichts anfangen. fdisk aus MS-DOS 6.22, sowie von FreeDOS ebenfalls nichts.
Einzig EZ-Drive hat die Platte zumindest sehen können, habe hier aber nicht weiterverfahren, da dies nicht zerstörungsfrei möglich gewesen wäre.

Also das Szenario ist: Die alte ATA1-Platte -> 486er eingebaut und auf dem 486er BasicLinux 3.50 Floppy Version gestartet.

Bezugsquelle

Von BasicLinux gibt es eine DOS-Version und eine Floppy-Version:

• DOS Version 3.50 - Intel 386, 3 MB RAM, DOS - Download - bl3-50.zip
• Floppy Version 3.50 - Intel 386, 12 MB RAM, 2 1,44 MB Floppy Disks - Download - bl3-50fd.zip

Ich habe beide Versionen probiert.

Floppy Version

Die Floppy-Version habe ich auf einen DOS-Rechner kopiert und von dort aus die Disketten erstellt nach deren Anleitung.

Erstellung

1. Zwei Floppies in DOS erstmal formatiert mit: format a: /u um auch zu prüfen, ob die Disketten reibungslos formatieren
2. Auf die zweite Floppy die DISK2.TGZ aus dem Floppy-Version Archiv raufkopiert
3. Die erste Floppy mit fdimage disk1.img a:
4. Den Rechner neustarten mit Diskette 1 zum Booten, eine Meldung erscheint wenn Diskette 2 eingelegt werden soll

Sicherung der Quellfestplatte

1. Dann ist man auch bald im Linux-Prompt. Dort erstelle ich mir auf /mnt erstmal Verzeichnisse zum Mounten der DOS-Partition auf die ich sichern möchte: mkdir -p /mnt/aptiva_c
2. Mit fdisk -l finde ich heraus wie die Partitionsschemen der Platten sind.
3. Dann mounte ich - in meinem Fall /dev/hda1 - auf eben erstelltem Mountpunkt: mount -t vfat /dev/hda1 /mnt/aptiva_c
4. Ich prüfe den Inhalt: cd /mnt/aptiva_c && ls -lah
   
5. Ist hier alles klar kann ich auch schon die Quellfestplatte sichern.
6. Das mache ich einfach mit dd und zwar mit: dd if=/dev/hdc of=st3120.img bs=64k
7. Nach ein paar Minuten ist der Prozess durch und ich prüfe mit ls -lah das fertige Image. 102 MB, passt.
   
8. Danach reboot eingeben, Diskette entfernen und wieder in DOS starten.
9. Ich nutze Windows 3.x für TCP/IP Netzwerk und Ordnerfreigabe, daher starte ich auch Windows.
10. Mit Linux verbinde ich mit altem SMB1 Protokoll auf den Windows 3.x Rechner und ziehe mir das Image runter.
    

    ❯ smbclient //IBM486/ARCHIVE -I 192.168.178.40 -N -p 139 --option="client min protocol=CORE" --option="client max protocol=LANMAN2"
    Try "help" to get a list of possible commands.
    smb: \> get st3120a.img
    getting file \st3120a.img of size 106954752 as st3120a.img (713,1 KiloBytes/sec) (average 713,1 KiloBytes/sec)
    smb: \> 
    

Mit PeaZip öffne ich die .img Datei und siehe da:

Wunderbar!

DOS Version

Ja... RTFM gilt hier. Der Ordnername MUSS C:\BASLIN heißen. Bei weniger als 8 MB RAM muss Auslagerungsspeicher aktiviert werden, dazu muss zusätzlich die swap.zip (im o.g. Ordner) entpackt werden.

Es wird ein "relatively clean DOS" erwartet, d.h. keine CONFIG.SYS, keine AUTOEXEC.BAT starten. Mit F5 kann man übrigens die Startsequenz bei MS-DOS überspringen.

Netzwerk

Netzwerk wird unterstützt indem man die Datei /root/netsetup seinen Gegebenheiten anpasst und dann ausführt.

In meinem Aptiva ist derzeit eine 3com Etherlink III verbaut (3c509). Ein Modul dafür ist aber standardmäßig nicht vorhanden, also werde ich es mir für Kernel 2.2.26 i386 extern besorgen müssen, auf die DOS Partition kopieren und von dort ins Linux System ins Verzeichnis /lib/modules/2.2.26/net.

Ich brauche also defintiv ein Modul passend zu Kernel 2.2.26. Habe ich bisher nicht gefunden, aber das Modul für Kernel 2.2.16 aus Slackware 7.1 scheint zu funktionieren! Das habe ich hier besorgt: 3c509.o - 3c509.o

Wenn das Internet nun funktioniert kann man sich Pakete aus z.B. Slackware 4.0 installieren. Eine Mirrorliste findet sich hier: Slackware Mirrorlist
Aktuell (20.08.2026) funktioniert hier beispielsweise der ungarische HTTP-Mirror. Eine Liste aller Dateien für z.B. Slackware 4.0 befindet sich in der FILELIST.TXT

Die Pakete können mit dem Links Textbrowser heruntergeladen werden. Ich habe mir in meinem Heimverzeichnis ~, entspricht /root den Ordner software angelegt, dort speichere ich heruntergeladene Pakete.
Mit links also den Browser starten und Taste G lässt einen Link eingeben: http://mirror.slackware.hr/slackware/
Hat man Pakete heruntergeladen lassen sie sich per: pkg <paketname.tgz> installieren.

Beispiel Workflow "deutsche Tastaturbelegung"

Ich schaue mir im Slackware 4.0 Verzeichnis in docs die Dokumentation Keyboard-and-Console-HOWTO an und stelle fest:

1.  Useful programs

  The following packages contain keyboard or console related programs.

  kbd-0.95.tar.gz contains loadkeys, dumpkeys, showkey, setmetamode,
  setleds, setfont, showfont, mapscrn, kbd_mode, loadunimap, chvt,
  resizecons, deallocvt, getkeycodes, setkeycodes.

Also ab geht's in die FILELIST.TXT und mit / (Slash) starten wir die Suche nach kbd.tgz (für das Binarypackage). Das liegt in a8, also auf in a8 und kbd.tgz herunterladen und später in der Shell mit pkg kbd.tgz installieren.
Jetzt mit loadkeys de-latin1-nodeadkeys die deutsche Tastaturbelegung aktivieren.

Sicherung einer Festplatte

Über Netzkatze 😺 - auf dem Ziel-PC zuerst starten (lauscht), dann den Prozess auf dem Quell-PC anstoßen.

Ziel-PC: nc -l -p 31337 | pv > festplatte.img
Quell-PC: dd if=/dev/hdc bs=64k | nc 192.168.178.X 31337

Ich musste auf meinem (Ziel-)PC noch den Port in der Firewall freigeben: sudo ufw allow 31337/tcp.

Und der Prozess läuft:

Kleiner Exkurs DD Raw Image vs .VHD

Um die 386SX HDD ST3120A bequem zu bespielen habe ich eine Festplatte in 86Box erstellt mit den gleichen Parametern C/H/S 1027/12/17 ≈ 102 MB. Sogar das exakte Modell war auswählbar: [ATA-1] Seagate ST3120A.
Leider habe ich übersehen, dass man auch ein Rohdatenabbild (.IMG) hätte machen können, daher wurde es ein .VHD Container mit fester Größe.

Nunja, dafür können wir jetzt einen kleinen Exkurs machen, wie .VHD aufgebaut ist und ob/wie man das per DD wieder zurückschreibt auf Echt-Hardware.

VHD-Format

VHD (Virtual Hard Disk) ist ein Containerformat ursprünglich von Microsoft Virtual PC für virtuelle Festplatten als Abbild. Der Container enthält als "Fixed hard disk Image" (feste Imagegröße) 1:1 die Daten wie z.B. von DD einer echten Festplatte übertragen PLUS 511 bzw. 512 Bytes Metadaten am Ende der Datei.
Quelle: Wikipedia-EN

Hier das Format des Footer im VHD-Container:

Quelle: Microsoft Corporation. 11 October 2006. - Virtual Hard Disk Format Spec_10_18_06.doc

Files:
* Virtual Hard Disk Format Spec_10_18_06.pdf
* Virtual Hard Disk Format Spec_10_18_06.doc

DD vs VHD die Dateien im Detail

Mit eza -lB können Dateien in Bytegröße angezeigt werden:

.rwxr-xr-x   106.954.752 marquisor 20 Aug 01:03 st3120a.img
.rw-r--r--   106.955.264 marquisor 22 Aug 15:02 ST3120A.VHD

Die .img ist die Originalsicherung der echten ST3120A und die .VHD das in 86Box erstellte Äquivalent.

Das Ende

Schauen wir uns die letzten 512 Bytes der VHD-Datei ST3120A.VHD also mal an:

❯ tail -c 512 ST3120A.VHD | xxd
00000000: 636f 6e65 6374 6978 0000 0002 0001 0000  conectix........
00000010: ffff ffff ffff ffff 321a 01e7 6d56 4844  ........2...mVHD
00000020: 000e 0000 5769 326b 0000 0000 0660 0000  ....Wi2k.....`..
00000030: 0000 0000 0660 0000 0400 0c11 0000 0002  .....`..........
00000040: ffff e6ed 479b ff9f c183 426f 9437 b72a  ....G.....Bo.7.*
00000050: 32c5 ffc6 0000 0000 0000 0000 0000 0000  2...............
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Das sind die Metadaten des VHD-Containers. Irrelevant für ein echtes Rohabbild (.img).
Kann also weg.

Schauen wir den Übergang (Offset 000001ff) an, die letzten 1024 Bytes der VHD-Datei ST3120A.VHD:

❯ tail -c 1024 ST3120A.VHD | xxd
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
000001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000200: 636f 6e65 6374 6978 0000 0002 0001 0000  conectix........
00000210: ffff ffff ffff ffff 321a 01e7 6d56 4844  ........2...mVHD
00000220: 000e 0000 5769 326b 0000 0000 0660 0000  ....Wi2k.....`..
00000230: 0000 0000 0660 0000 0400 0c11 0000 0002  .....`..........
00000240: ffff e6ed 479b ff9f c183 426f 9437 b72a  ....G.....Bo.7.*
00000250: 32c5 ffc6 0000 0000 0000 0000 0000 0000  2...............
00000260: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
000003f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Alles 0000, also unkritisch.

Schauen wir das Ende des Rohabbilds der echten Festplatte an st3120a.img:

❯ tail -c 512 st3120a.img | xxd
00000000: 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c  llllllllllllllll
00000010: 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c  llllllllllllllll
...
000001f0: 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c  llllllllllllllll

Auch nix wichtiges, aber hätte ja sein können...

Der Anfang

Aus reinem Interesse schauen wir mal auf den Anfang der VHD-Datei und des Rohdatenabbildes.

Der Anfang der VHD-Datei ST3120A.VHD:

❯ head -c 1024 ST3120A.VHD | xxd
00000000: fa33 c08e d0bc 007c 8bf4 5007 501f fbfc  .3.....|..P.P...
00000010: bf00 06b9 0001 f2a5 ea1d 0600 00be be07  ................
00000020: b304 803c 8074 0e80 3c00 751c 83c6 10fe  ...<.t..<.u.....
00000030: cb75 efcd 188b 148b 4c02 8bee 83c6 10fe  .u......L.......
00000040: cb74 1a80 3c00 74f4 be8b 06ac 3c00 740b  .t..<.t.....<.t.
00000050: 56bb 0700 b40e cd10 5eeb f0eb febf 0500  V.......^.......
00000060: bb00 7cb8 0102 57cd 135f 730c 33c0 cd13  ..|...W.._s.3...
00000070: 4f75 edbe a706 ebd3 becd 06bf fe7d 813d  Ou...........}.=
00000080: 55aa 75c7 8bf5 ea00 7c00 0055 6e67 816c  U.u.....|..Ung.l
00000090: 7469 6765 2050 6172 7469 7469 6f6e 7374  tige Partitionst
000000a0: 6162 656c 6c65 0046 6568 6c65 7220 6265  abelle.Fehler be
000000b0: 696d 204c 6164 656e 2064 6573 2042 6574  im Laden des Bet
000000c0: 7269 6562 7373 7973 7465 6d73 0042 6574  riebssystems.Bet
000000d0: 7269 6562 7373 7973 7465 6d20 6665 686c  riebssystem fehl
000000e0: 7400 0000 0000 0000 0000 0000 0000 0000  t...............
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
000001c0: 0100 060b d1fe 1100 0000 232f 0300 0000  ..........#/....
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.
00000200: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000210: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
000003f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

Der Anfang des Rohabbilds der echten Festplatte st3120a.img:

❯ head -c 1024 st3120a.img | xxd
00000000: fa33 c08e d0bc 007c 8bf4 5007 501f fbfc  .3.....|..P.P...
00000010: bf00 06b9 0001 f2a5 ea1d 0600 00be be07  ................
00000020: b304 803c 8074 0e80 3c00 751c 83c6 10fe  ...<.t..<.u.....
00000030: cb75 efcd 188b 148b 4c02 8bee 83c6 10fe  .u......L.......
00000040: cb74 1a80 3c00 74f4 be8b 06ac 3c00 740b  .t..<.t.....<.t.
00000050: 56bb 0700 b40e cd10 5eeb f0eb febf 0500  V.......^.......
00000060: bb00 7cb8 0102 57cd 135f 730c 33c0 cd13  ..|...W.._s.3...
00000070: 4f75 edbe a706 ebd3 becd 06bf fe7d 813d  Ou...........}.=
00000080: 55aa 75c7 8bf5 ea00 7c00 0055 6e67 816c  U.u.....|..Ung.l
00000090: 7469 6765 2050 6172 7469 7469 6f6e 7374  tige Partitionst
000000a0: 6162 656c 6c65 0046 6568 6c65 7220 6265  abelle.Fehler be
000000b0: 696d 204c 6164 656e 2064 6573 2042 6574  im Laden des Bet
000000c0: 7269 6562 7373 7973 7465 6d73 0042 6574  riebssystems.Bet
000000d0: 7269 6562 7373 7973 7465 6d20 d094 a71a  riebssystem ....
000000e0: 7400 0000 0000 0000 0000 0000 0000 0000  t...............
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
000001c0: 0100 060b d1fe 1100 0000 232f 0300 0000  ..........#/....
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.
00000200: 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c  llllllllllllllll
00000210: 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c  llllllllllllllll
...
000003f0: 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c 6c6c  llllllllllllllll

Der ultimative Vergleich

Der Vergleich geht auch wesentlich komfortabler mit vbindiff:

4 Bytes Unterschied, warum gerade das Wort fehl, ich habe keine Ahnung, soll mir aber auch egal sein.

Quintessenz

Da am Ende der VHD-Datei 512 Bytes Metadaten sind, beim Übergang keine Daten, beim Image der echten Platte auch nix wichtiges und überhaupt aus Prinzip der Sache der 1:1 Kopie mit DD über netcat gestreamt nicht mehr Daten geschrieben werden können als Platz auf dem Ziel ist:
Die Daten aus der Datei ST3120A.VHD können mit DD exakt wie ein Rohabbild auf die Original Festplatte übertragen werden.

Mal was abschneiden

Da mein innerer Monk damit aber unzufrieden ist, und wir noch was lernen wollen, kopieren wir jetzt die VHD-Datei in eine .img-Datei und schneiden einfach 512 Bytes ab.

Datei kopieren:
cp ST3120A.VHD st3120a_to_386sx.img

512 Bytes abschneiden:
truncate -s -512 st3120a_to_386sx.img

Ergebnis:

 106.954.752 st3120a.img        (Original)
 106.955.264 ST3120A.VHD        (Neu bespielt)
 106.954.752 st3120a_to_386sx.img   (Kopie der neu bespielten, 512 Bytes abgeschnitten)

Ja? Wurde wirklich das Ende abgeschnitten? Überprüfen wir den Kopf:

❯ head -c 512 st3120a.img | xxd
00000000: fa33 c08e d0bc 007c 8bf4 5007 501f fbfc  .3.....|..P.P...
00000010: bf00 06b9 0001 f2a5 ea1d 0600 00be be07  ................
00000020: b304 803c 8074 0e80 3c00 751c 83c6 10fe  ...<.t..<.u.....
00000030: cb75 efcd 188b 148b 4c02 8bee 83c6 10fe  .u......L.......
00000040: cb74 1a80 3c00 74f4 be8b 06ac 3c00 740b  .t..<.t.....<.t.
00000050: 56bb 0700 b40e cd10 5eeb f0eb febf 0500  V.......^.......
00000060: bb00 7cb8 0102 57cd 135f 730c 33c0 cd13  ..|...W.._s.3...
00000070: 4f75 edbe a706 ebd3 becd 06bf fe7d 813d  Ou...........}.=
00000080: 55aa 75c7 8bf5 ea00 7c00 0055 6e67 816c  U.u.....|..Ung.l
00000090: 7469 6765 2050 6172 7469 7469 6f6e 7374  tige Partitionst
000000a0: 6162 656c 6c65 0046 6568 6c65 7220 6265  abelle.Fehler be
000000b0: 696d 204c 6164 656e 2064 6573 2042 6574  im Laden des Bet
000000c0: 7269 6562 7373 7973 7465 6d73 0042 6574  riebssystems.Bet
000000d0: 7269 6562 7373 7973 7465 6d20 d094 a71a  riebssystem ....
000000e0: 7400 0000 0000 0000 0000 0000 0000 0000  t...............
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...

Passt.

Zurück zum Original

Die Datei kopiere ich dann jetzt mit umgekehrter Methode - Netzkatze 😺 - wieder zurück.

Ich baue die Platte wieder an den 2. IDE-Kanal des 486er:
IDE-Kabel vom 486er CD-ROM abgeklemmt -> HDD angeklemmt, Strom nicht vergessen!
DOS des 486 starten, Startdateien umgehen mit F5 und BasicLinux von DOS aus booten.

In Linux lade ich die deutsche Tastaturbelegung:
loadkeys de-latin1-nodeadkeys

Sowie den Netzwerktreiber (Kernelmodul) und den DHCP-Client:
insmod 3c509
udhcpc

Mit ifconfig finden wir die IP-Adresse des 486ers raus: 192.168.178.40.
Und mit fdisk -l überprüfen wir nochmal welche Festplatte wir hier beschreiben wollen.

!!! ACHTUNG! Hier unbedingt drauf achten die korrekt Platte zu wählen, sonst wird die Bootfestplatte des 486er überschrieben !!!

Diesmal netcat auf dem 486, das ist jetzt der Ziel-PC zuerst starten (lauscht), dann den Prozess auf dem Quell-PC anstoßen.

Ziel-PC: nc -l -p 31337 > /dev/hdc
Quell-PC: dd if=st3120a_to_386.img bs=64k | nc 192.168.178.40 31337

Diesmal gibt es leider keine Progress-Anzeige, pv hab ich auf dem 486er Linux nicht, das hier soll als Bild reichen:

Der Sende-PC vermeldet nach ca. 10 Minuten:

❯ dd if=st3120a_to_386sx.img bs=64k | nc 192.168.178.40 31337
1632+0 Datensätze ein
1632+0 Datensätze aus
106954752 Byte (107 MB, 102 MiB) kopiert, 572,172 s, 187 kB/s

Feddich.

Auf dem 486er beenden wir jetzt auch den Lauscher, dazu drücken wir jetzt Strg+C und führen zweimal sync aus und damit ist das Image jetzt wohl auf der 386er Platte.

Prüfung

Auch hier können wir wieder prüfen, was am Anfang und Ende der Platte ist.

Die Macht der Quersumme

Da auf dem 486er nur eine rudimentäre Busybox-Umgebung läuft sind die Befehle sehr begrenzt. head und tail gibt es zwar, ist aber ohne einen Hexdumper wie xxd oder hexdump nicht sinnvoll nutzbar. Es zerstört sogar die Kommandozeile, da Sonderzeichen ausgegeben werden ohne die Pipe an entsprechendes Programm.

Daher nehmen wir folgenden Trick, wir nehmen einfach die ersten XXXX Bytes und vergleichen die Quersumme.

Auf dem 486er (die ersten 1024 Bytes):
dd if=/dev/hdc bs=1024 count=1 | md5sum:

1+0 records in
1+0 records out
2ace894a4702d3ef9bb2b90096e94712 -

Auf dem Quell-PC:
dd if=st3120a_to_386sx.img bs=1024 count=1 | md5sum

1+0 Datensätze ein
1+0 Datensätze aus
1024 Byte (1,0 kB, 1,0 KiB) kopiert, 5,2651e-05 s, 19,4 MB/s
2ace894a4702d3ef9bb2b90096e94712  -

Das geht natürlich auch mit 1 MB usw., habe ich geprüft, gleiche MD5 472070b42ea6413ecfde77950fecefc0.

Gut, zusammenpacken, Ende!

/<#>poweroff
The system is going down NOW !!
Sending SIGTERM to all processes.
Sending SIGKILL to all processes.
The system is halted. Press Reset or turn off power
Power down.

Ob die Festplatte dann im 386SX läuft werde ich die Tage sehen. Jetzt mache ich mir erstmal ein Bier auf. Prost!