Der Disk-Dump aus der Urzeit

Der Disk-Dump aus der Urzeit

Das Kopiertool dd gehört seit den 1970er Jahren wohl ebenso wie ls, cd oder tar fast zu jedem “unixoiden” Betriebssystem. Nicht nur deshalb sollte man es als Nutzer eines solchen Systems kennen, sondern vor allem, weil es sehr vielseitig verwendbar ist und die Unix-Philosophie “everything is a file” verdeutlicht.

dd kann Daten zwischen Dateien und beliebigen Datenspeichern austauschen. Dabei wird davon ausgegangen, dass die Grundfunktion jedes Speichers der serielle Austausch von Daten ist - auch ohne dass es so etwas wie ein “Dateisystem” gibt. Auf dieser “primitiven” seriellen Ebene spricht man von “raw devices”. Wenn das Gerät Daten auch blockweise (mit Sektoren, Records) positionieren und übertragen kann, nennt man es “block device” und kann diverse Dateisysteme mit diesen Blöcken aufbauen.

Beispiele:

  • Terminalschnittstellen wie /dev/tty1 oder Drucker wie /dev/lpt1 sind “raw devices”
  • Festplatten wie /dev/sda, Speicherkarten wie /dev/mmcblk und der Arbeitsspeicher /dev/mem sind “block devices” und können mit einem Dateisystem erweitert werden.
  • bei Netzwerkzugriff gibt es eine Raw-Ebene für zeichenweise Übertragung (ISO Layer 1) und eine Block-Ebene (ab ISO Layer 2).

Wie auch tar oder cpio kann dd Daten zwischen raw-devices und block-devices bzw. Dateien übertragen, also Dateien oder Blöcke serialisieren und serialisierte, “rohe” Daten in einer “Image-Datei” ablegen - und das mit allen Geräten und Dateisystemen.

Das ermöglicht “Images” von beliebigen Festplatteninhalten, CDs, DVDs, RAM-Disks etc. als Datei abzulegen und solche Backups woanders wieder herzustellen. Mittels loop devices kann man solche Images sogar als Block-Device mounten, also z.B. das Image einer CD als virtuelle CD in den Dateibaum laden.

Beispiel: Mount einer virtuellen /root Partition aus einer Image-Datei Um die Partitionen in einer Imagedatei anzuzeigen kann man fdisk nutzen:

$ fdisk -l red-node-raspi.img
Festplatte red-node-raspi.img: 2,7 GiB, 2894069760 Bytes, 5652480 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x92b764b9

Gerät               Boot Anfang    Ende Sektoren Größe Kn Typ
red-node-raspi.img1        8192  532479   524288  256M  c W95 FAT32 (LBA)
red-node-raspi.img2      532480 5652479  5120000  2,4G 83 Linux

Dies Image hat also Sektoren je 512 Byte, also beginnt die Partition Linux bei einem Offset von 532480 * 512 = 272629760 Bytes. Mit einem Loop device kann man diese Partition direkt in ein leeres Verzeichnis /mnt mounten:

$ sudo mount -o loop,rw,sync,offset=272629760 red-node-raspi.img /mnt
[sudo] Passwort für kzerbe: ****
$ ls /mnt
bin   dev  home  lost+found  mnt  proc  run   srv  tmp  var
boot  etc  lib   media       opt  root  sbin  sys  usr

Mit dem so eingebundenem virtuellen Laufwerk kann genauso gearbeitet werden wie mit dem echten Gerät, ja mit rw kann man in ein so eingebundenes CD-Image auch schreiben, um es anschließend mit dd auf eine andre CD zu brennen. Häufig benötigt man solche virtuellen Mounts für Untersuchungen des Linux Boot-Vorgangs, was über ein Ramdisk-Image /boot/initrd.img, geschieht. Diesen Boot Prozess beschreibe ich in Wie sich Computer aus dem Datensumpf ziehen genauer.

Das Programm dd kann noch für allerlei Zeichensatz-Konvertierungen etc. eingesetzt werden, um Medien (etwa Tapes) eines “fremden” Computersystems (etwa IBM-Großrechner) lesen zu können. dd --help zeigt dabei eine Vielzahl von Möglichkeiten.

Um Betriebssystem- Boot-Disks (nicht nur Linux) als Datei abzulegen und so bootbare Medien wie CD, DVD, Speicherkarte, USB-Stick etc. herzustellen, ist dd also ebenso wie für full backups von Rechnern ein ideales Werkzeug. Für diese Zwecke ist dd auch sehr einfach zu verwenden:

$ sudo dd if=raspi-os.img of=/dev/sdc bs=8M

Dabei bezeichnet if=raspi-os.img die Quell-Imagedatei und of=/dev/sdc eine Festplatte oder einen USB-Speicher als Ziel-“Raw Device”. Mit bs=8M kann eine größere Blockgröße angegeben werden, um das Kopieren durch größere Puffergrößen zu beschleunigen. Der Standardwert orientiert sich leider an uralter Hardware mit wenig Arbeitsspeicher, selbst beim Raspberry können aber 8M für 8 Megabyte pro Block nicht schaden.

So ein Befehl ist leider nicht ganz ungefährlich, denn dd nimmt keine Rücksicht darauf, was sich auf dem Zielgerät bereits befindet. Dort bereits vorhandene Dateisysteme werden einfach überschrieben - also auch Disk-Partitionen des Geräts, mit dem man kopiert. “Tippfehler” sollte man unbedingt vermeiden und überprüfen, ob das angegebene Zielgerät wirklich die Speicherkarte ist, die man beschreiben will.

Mit dem Befehl …

$ sudo dmesg | tail -n 30 

… kann man feststellen, ob kürzlich ein USB-Speicher mit welchem Gerätenamen angeschlossen wurde. Das Kommando mount zeigt darüberhinaus an, welche Geräte unter welchem “Mountpoint” gerade im System erreichbar sind. Hier sollte man im Zweifelsfall besser nachschauen.

Ein weiteres Problem kann der “automount” von externen Geräten wie CDs oder USB-Speicher sein. Diese Mounts sollte man mit …

$ sudo umount /dev/sdXX

… besser entfernen oder zumindest keine Zugriffe während des Kopiervorgangs durchführen.

Wenn dd mit dem Kopieren fertig ist, also wieder eine Befehlseingabe möglich ist, sollte wegen des Schreib-Caches unbedingt noch ein …

$ sudo sync

… ausgeführt werden, bevor man das neue Medium entfernt. Vor dem Entfernen darf auch kein “umount” oder Auswerfen der neuen Kopie erfolgen (sofern man das nicht vor dem Kopieren erledigt hat), sonst überschreibt das noch gemountete alte Dateisystem die neue Kopie. Nachdem das sync abgeschlossen ist, sollte das neue Medium also gleich entfernt werden. Der sync kann erheblich länger dauern als die Ausführung von dd, wenn ein System einen großen Disk-Cache hat. Einige hundert Megabyte auf eine langsame Speicherkarte zu schreiben, kann durchaus ein paar Minuten dauern.

War dieser Artikel hilfreich? Bewertungen: 0
Artikeldetails:
Veröffentlichungsdatum: 2020-12-30 5:57PM
Zuletzt aktualisiert: 2020-12-31 2:56PM (Klaus - klaus@zerbe.cloud)
Artikel teilen: 
Autor: Klaus (klaus@zerbe.cloud)
Permalink: http://openkb.zerbe.cloud/kb/der-disk-dump-aus-der-urzeit