Dd

Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

 --Robi 19:40, 7. Jul 2007 (CEST)

das Kommando dd

allgemeines zum Kommando dd

dd ist ein Kommando das noch aus der Urzeit von UNIX stammt. Der Name sollte früher Copy and Convert bedeuten, das Programmkürzel cc war jedoch schon an den C-Compiler vergeben. Daher kam es wohl kurzerhand zu dd. Heute wird dieses Kürzel oftmals als disk dump oder ähnlich übersetzt, ursprünglich sollte es wohl doch mehr an das JCL-Kommando "Data Definition" erinnern, auch die für UNIX-Befehle doch sonderbaren Optionensschreibweisen erinnern noch sehr stark an diese Abstammung.

Das UNIX-Kommando dd dient dem Umleiten von Datenstömen. Dabei kann es diese Datenströme Byteweise bearbeiten und universell blocken. Als Quelle und Ziel der Datenströme können sowohl normale Dateien, die normalen Ein- und Ausgabekanäle der Prozesse und auch Geräteknoten verwendet werden. In früherer Zeit benötigte man das Programm dd , um inkompatible Formate und Zeichensätze zwischen unterschiedlichen Betriebssystemen und Geräten zu kopieren, und um Daten auf externen Peripheriegeräten (oftmals Bandgeräte) lesen und schreiben zu können.

Typischen Beispielaufgaben aus dieser Zeit könnten heute auf Linux etwa so ausgesehen:

• Auslesen eines EBCDIC-Bandes (80 Zeichen pro Record, 10 Records pro Block, Dichte 1600 bpi) Ausgabe als Ascii-Datei:

   dd if=/dev/nst1 of=/datei ibs=800 cbs=80 conv=ascii,lcase

Für Konvertierungsaufgaben benötigt man heute dd nur noch wenig. Dort wo noch mit solchen inkompatiblen Daten gearbeitet wird, benutzt man heute meist Programme die schon die entsprechende Ein- und Ausgabefilter mitbringen. Wohl aber benötigt man auch heute noch die universellen Bockungsmöglichkeiten von dd in Bezug auf Datenströme und Geräteknoten, sowie die Möglichkeit im Datenstrom gezielt zu positionieren. Besondere "Berühmtheit" hat heutzutage jedoch die Möglichkeit erlangt, Partitionen und ganze Festplatten bytegenau zu kopieren, was fälschlicher Weise dazu verleitet mag dd auch noch in den Rang eines Backuptools zu erheben.

die Optionen von dd

Die Optionen von dd unterscheiden sich grundlegend von denen der meisten UNIX/Linux Kommandos. Eine Übersicht erhaltet ihr mit der Option --help oder der Manpage von dd ( Achtung: evtl. sind nicht alle Optionen in eurer installierten Version vorhanden). Auch eine Infoseite "info:/coreutils/dd invocation" sollte bei vielen installiert sein.

Die genaue SYNOPSIS (ältere Version)

dd [--help] [--version] [if=file] [of=file] [ibs=bytes] [obs=bytes] [bs=bytes] [cbs=bytes] [skip=blocks]
[seek=blocks] [count=blocks] [conv={ascii, ebcdic, ibm, block, unblock, lcase, ucase, swab, noerror, notrunc, sync}]

Die wichtigsten Optionen im Überblick

if=Datei	Der Datenstrom, der umgeleitet werden soll. Das kann eine Datei oder Gerätedatei, also auch eine Festplatte oder ein anderes Gerät sein. Wird if weggelassen liest dd von der Standardeingabe.
of=Datei	Die Datei, auf die geschrieben werden soll. Dies kann wieder eine Datei oder ein Gerät sein. Wird of weggelassen schreibt dd auf die Standardausgabe.
ibs=Bytes	Eingabe-Blockgröße (input block size), gibt an, wie viele Bytes auf ein Mal gelesen werden sollen.
obs=Bytes	Ausgabe-Blockgröße (output block size), gibt an, wie viele Bytes auf ein Mal geschrieben werden sollen.
bs=bytes	Kurzschreibweise für ibs=bytes obs=bytes. Der Standardwert bei Nichtangabe ist 512 Bytes.
count=Blocks	Angabe, um nur eine begrenzte Menge Blöcke zu kopieren.
skip=Blocks	Angabe, um eine Anzahl Blocks beim lesen am Anfang zu überspringen.
seek=blocks	Überspringt diese Anzahl Blöcke beim schreiben auf die Ausgabe.
conv=Schlüsselwörter	Wandelt den Datenstrom entsprechend einer Kommagetrennten Liste von Schlüsselwörtern.
cbs=Bytes	Umwandlungs-Blockgröße (convert block size): Größe der Blöcke zum Umwandeln auf ein Mal.

die Ein- und Ausgabefile

Beide Filenamen werden in den Optionen angegeben nach folgenem Prinzip

if=/PATH/EINGABEDATEI   #die Datei oder Gerät aus dem gelesen wird
of=/PATH/AUSGABEDATEI   #die Datei oder Gerät auf das geschrieben wird

sollte einer oder beide nicht explizid so angegeben werden, dann wird von dd automatisch mit dem entsprechenden Standard-Ein/Ausgabe-Kanal gearbeitet. Man kann immer jeweils nur einen Dateinamen angeben es geht also weder eine Space- noch Kommaseparierte Liste und auch die Shell übernimmt hier keine Path- oder Filenamensexpansionen. Nur relative und absolute Dateiadressierung sowie die tilde expansion sind zulässig, ansonsten sind immer komplette absolute oder relative Path und kompletter Dateinamen anzugeben. Auf den Inhalt von Variablen für die Dateinamen kann zugegriffen werden, soweit im Dateinamen Sonderzeichen enthalten sind muß das aber im dd-Komando unbedingt berücksichtigt werden.
Beispiel:

NULL=/dev/null                  
INFILE="/home/user/datei orginal"
dd if="$INFILE" of=$NULL 

Achtung:

Beim Zugriff auf Geräteknoten, also zB Festplatten, Partitionen, Bandgeräte usw. immer einmal mehr prüfen ob nicht doch if und of verwechselt wurden. Es droht hier bei Verwechslungen unter Userkennung root Datenverlust.

die Blockgröße

Die Blockgröße gibt an, wieviele Byte bei einem read- oder write-Kommando gleichzeitig verarbeitet werden. Im Normalfall ist man unter Linux ja gewohnt, dass man sich darum überhaupt nicht kümmern muss, das macht Linux im Hintergrund für uns immer richtig. Da wird zB von der Tastatur jedes einzelne Zeichen gelesen, Eingaben werden zeilenweise nach Bestätigung der ENTER-Taste verarbeitet, auf die Festplatte wird mittels des Caches mit 4KB Blockgröße lesend und schreibend zugegriffen, über Internet werden Pakete mit maximaler Größe von 1500 Byte gesendet usw. Alles Dinge von denen wir gar nichts mitbekommen, und von denen wir auch die meisten überhaupt nicht beeinflussen könnten, selbst wenn wir das wollten.

Anders jedoch beim Befehl dd. Hier arbeitet der Befehl, sollten wir nichts anderes angeben, immer mit 512 Byte lesend und schreibend und hier können wir das sowohl beim lesenden- wie auch den schreibenden-Zugriff und sogar getrennt beeinflussen.

Zu was soll das gut sein, werden sich die meisten fragen.
Eine Regentonne voll mit Wasser kann man sowohl mit einem Eimer, mit einer Suppenkelle aber auch mit einem Kaffeelöffelchen "leerschaufeln", was ist wohl die schnellste und rückenschonendste Methode? Ähnlich verhalten sich viele Geräte wenn wir direkt zB über dd auf sie zugreifen.

Im folgende Beispiel wird eine kleine Partition einer SCSI-Platte mit "NULLEN" überschrieben, wobei mit der Blockgröße von dd gespielt wird.

 time dd if=/dev/zero of=/dev/sdb1 bs=512

(wobei bei bs= die Werte 16 64 512 2K 8K 32K und 128K zum Einsatz kamen)

Blockgröße	real time	user time	sys time
16 Byte	2m26.593s	0m7.898s	1m2.839s
64 Byte	1m39.600s	0m2.734s	0m23.812s
512 Byte	1m18.710s	0m0.465s	0m6.942s
2 KByte	1m16.131s	0m0.100s	0m3.552s
8 KByte	0m29.137s	0m0.016s	0m1.299s
32 KByte	0m29.159s	0m0.012s	0m1.507s
128 KByte	0m29.115s	0m0.003s	0m1.474s

Wir erkennen, die default Einstellung von dd (512 Byte) ist zwar auf dieser Platte nicht die Allerschlechteste, aber es geht durchaus noch 3 Mal schneller. Da moderne Festplatten in der Regel heute einen Cache haben der zumindestens beim Lesen genutzt ist, ergeben sich beim Lesen von Partitionen oder ganzen Festplatten oftmals ganz andere (weniger unterschiedliche) Werte.

Wesentlich gravierender sind die Unterschiede jedoch bei Bandlaufwerken, es gibt verschiedene Möglichkeiten wie das Laufwerk die ihm übertragene Blockgröße interpretieren soll, man muss prinzipiell jeden Block mit der selben Blocksize lesen, mit der der Block auch geschrieben wurde, eine ungünstige Blockgröße kostet nicht nur Zeit sondern bedeutet auch erhöhten Verschleiß an Bandmaterial und Laufwerk und nicht zuletzt auch noch ein höheres Fehlerrisiko. Wer sich näher damit befassen will oder muss kann unter Bandlaufwerke und Linux und speziell über die richtige Blockgröße bei Bandlaufwerken im Wiki näher infomieren.

Es gibt im Internet die abendteuerlichsten Berechnungsmodelle für die "richtige Blockgröße" von dd für den Zugriff auf Festplatten. Man geht dabei von der Ausgabe des fdisk-Befehles aus, und errechnet aus den dort ausgegebenen Werten der Köpfen, Sektoren, Cylindern und Units irgendwie eine "optimale Blockgröße" und kommt dann auf solche Werte wie zB. 16065 Byte.[1]
Abgesehen, dass solche Werte dann manchmal nicht einmal durch 512 (die kleinste Speichereinheit auf einer Festplatte) teilbar sind, schon eine einfache Überlegung müsste den völligen Unsinn eines solchen Unterfangens aufzeigen.

LINUX:~ # fdisk -l /dev/sdb

Disk /dev/sdb: 18.2 GB, 18275768320 bytes
255 heads, 63 sectors/track, 2221 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
.......

Diese Festplatte, die laut Hersteller 5 Scheiben mit je 2 Köpfen hat, sollte jetzt plötzlich 255 Köpfe haben. Damit müsste sie nach heutiger Bauweise in etwa 30 bis 35 cm dick sein und hätte ein stattliches Gewicht von einigen kg. Also absolute Vorsicht mit solchen Berechnungen. Die heutigen Platten verwalten intern ihre eigene Geometrie und werden von außen nur über LBA-Verfahren angesprochen. Die Geometrie die uns zB fdisk nach außen zeigt, ist eine reine logische die mit der tatsächlichen nur eines gemein hat, die ungefähre (etwas kleiner) Gesamtgröße, und kann mit Befehlen wie zB. fdisk bei Bedarf auch angepasst oder geändert werden.

Die optimalsten Werte sind von eine Vielzahl von vor allem baulichen Faktoren abhängig und werden heute in vielen Geräten obendrein noch über Cache in den Geräten gepuffert, womit man mit größeren Werten nie falsch liegen kann.
Prinzipiell, (wenn keine anderen Faktoren dagegen sprechen- siehe Positionierung im Datenstrom) nur Werte die durch 512 teilbar sind, für Disketten, kleine Speicherkarten und kleine Sticks und ganz alte oder schon teilweise defekte Platten 512 Byte, für die restlichen Platten 4 oder 8 KByte, bei CD-ROM und DVD 1 oder 2 KByte und für MO-Disk UDO und andere WORM, nur die vom Hersteller und der jeweiligen Technologie vorgeschriebenen Blockgröße, und man sollte auf der richtigen Spur sein.

Positionierung innerhalb des Datenstrom

Als Datenstrom bezeichnen wir hier mal alles, womit dd arbeiten kann, also zB. Pipe, Datei, Gerät,...
DD kennt als Bezugspunkt immer nur den Anfang von Eingangsstrom und Anfang vom Ausgangsstrom. Da man aber nicht immer den kompletten Eingangsstrom bis zum Ende auf Ausgangsstrom von Anfang an kopieren will, muss man innerhalb dieser beide Datenströme auch positionieren können. Das geht mit den Optionen skip= seek= und count= und diese sind jeweils von den gesetzten Blockgrössen abhängig.

Wenn wir dd ohne solche Positionierungs-Optionen starten, dann kopiert dd den Eingangsdatenstrom von Anfang bis ein EOF (End Of File) kommt, komplett auf den Ausgangsdatenstrom. Bei Lese- oder Schreibfehlern wird an dieser Stelle dd abgebrochen. Ein EOF kann das Ende einer normalen File sein, aber auch zB der Abbruch eines am Eingang über Pipe verbundenen Befehles. Auch der Versuch zB. über eine Gerätegrenze (zB Partition zu Ende) zu lesen oder schreiben, führt zu einen EOF Fehler.

Die Gesamtanzahl der zu kopierenden Blöcke kann mit der Option count= begrenzt werden.

count=100    

kopiert genau 100 Blöcke ( Eingangsblockgröße )

Es können am Eingangsstrom anfänglich Blöcke (Eingangsblockgröße) übersprungen werden, die dann nicht mit kopiert werden, und die auch nicht von einem eventuell gesetzem count-Wert abgezogen werden. Die Option dazu ist skip=

skip=100 count=50  

kopiert genau 50 Blöcke (Eingangsblockgröße) wobei am Anfang 100 (Eingangsblockgröße) übersprungen werden, bevor mit dem kopieren begonnen wird.

Es können am Ausgangsstrom anfänglich Blöcke (Ausgangsblockgröße) übersprungen werden bevor der erste Block dorthin kopiert wird. Diese Option ist seek=.

seek=100 count=50 

kopiert die ersten 50 Blöcke (Eingangsblockgröße) vom Eingangstrom ab dem 101 Block (Ausgangsblockgröße) in den Ausgangsstrom. (Die ersten 100 Blocke der Größe obs= bleiben also im Ausgangsstrom unberührt, erst danach kommt der erste kopierte Block) Diese Option macht nicht mit allen Ausgangsdatenströmen Sinn, und führt zB. in Verbindung mit der Standardausgabe zum "hängenbleiben" des Befehles, da ja erstmal auf Daten gewartet werden muss, die gar nicht kommen können. Beim Anwenden auf normale Dateien führt ein zu großer seek-Wert (größer als Ausgangsdatei) zum weiterschreiben der Datei am Ende.

Soweit zur Theorie und zu den wichtigsten Optionen

die Ausgaben von dd

Wir untersuchen dazu einmal exemplarisch eine Ausgabe eines dd-Befehls, hier wurde von der Partition /dev/sda2 mit einer Blockgröße von 8KByte gelesen und auf ein Tape /dev/nst0 mit 256 KByte Blockgröße geschrieben.

LINUX:~ # dd if=/dev/sda2 of=/dev/nst0 ibs=8K obs=256K
262256+0 records in
8195+1 records out
2148401152 bytes (2.1 GB) copied, 74.8721 seconds, 28.7 MB/s

262256+0 records in 

es wurden 262256 Blöcke a. 8K gelesen, die +0 bedeuten, es gab am Ende keine Rest, also der letzte Block hatte wirklich auch 8K Größe.

8195+1 records out 

es wurden 8195 Blöcke a. 256K geschrieben, die +1 bedeutet, es wurde zusätzlich noch ein Restbock geschreiben, der nicht die volle Größe von 256K hatte. Wenn mit der Option "bs=" gearbeitet wird, oder die Blockgrößen sonst wie für Ein/Ausgabe gleich sind, dann sollten bei einem ordnungsgemäßen Ablauf des Befehls beide Werte immer gleich ausfallen.

2148401152 bytes (2.1 GB) copied, 74.8721 seconds, 28.7 MB/s 

die Schlußzeile erhalten wir nur in neueren Versionen von dd. Sie beinhaltet hier die Gesamtanzahl der übertragenen Byte die Zeit und die durchschnittliche Geschwindigkeit.

Solange der Befehl dd läuft erhalten wir ansonsten von ihm keinerlei Ausgaben. Wir können uns aber den Status der aktuell übertragenen Daten in der oben beschriebenen Form anzeigen lassen, indem wir dem dd-Prozess ein Signal 10 (SIGUSR1) senden. Alle diese Ausgaben kommen über den Standardfehlerausgabekanal des Prozesses dd.

Anwendungsgebiete und Beispiele

mit dd Dateien erzeugen

Hin und wieder benötigt man spezielle Dateien in bestimmter Größe und mit typischen oder speziellen Inhalt. Das können einfach Dateien sein, die man zum testen benötigt oder auch Dateien um darin zB Filesysteme anzulegen oder oder oder.
Das geht mit dd sehr einfach. Wir benötigen nur einen Quelldatenstrom dazu. Auf die Blockgrößen brauchen wir hier meistens gar nicht zu achten (eventuell/selten könnte aber der gewünschte Quelldatenstrom eine Blockgröße fordern), da das Filesystem in das wir unsere Datei schreiben sowieso gebuffert ist, also können wir mit bs= und count= unsere gewünschte eindeutige Dateigröße sehr schön festlegen.

Blockgröße x Count = Dateigröße

Erzeugen einer mit Nullen gefüllten Datei

Als Quelldatenstrom nutzen wir dazu /dev/zero ( nicht /dev/null , da beim lesen von /dev/null nur ein EOF zurückgeliefert wird und wir eine Datei mit Länge Null erhalten würden)

robi@LINUX:~/test> dd if=/dev/zero of=file.leer bs=1M count=1024
1024+0 Datensätze ein
1024+0 Datensätze aus

erzeugt eine 1GB große (ergibt sich aus 1MByte x 1024) Datei voller Nullen

Erzeugen von Sparse Dateien

robi@LINUX:~/test> dd if=/dev/zero of=file.sparse count=0 obs=1 seek=1G
0+0 Datensätze ein
0+0 Datensätze aus
robi@LINUX:~/test> ls -l file.*
-rw-r--r--  1 robi users 1073741824 2007-06-29 23:37 file.leer
-rw-r--r--  1 robi users 1073741824 2007-06-30 01:24 file.sparse
-rw-r--r--  1 robi users 1073741824 2007-06-30 00:12 file.zufall
robi@LINUX:~/test> stat file.sparse
  File: ,,file.sparse"
  Size: 1073741824      Blocks: 0          IO Block: 4096   reguläre Datei
Device: 802h/2050d      Inode: 1038268     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1001/    robi)   Gid: (  100/   users)
Access: 2007-06-30 01:24:39.168204352 +0200
Modify: 2007-06-30 01:24:39.168204352 +0200
Change: 2007-06-30 01:24:39.168204352 +0200

Schreibt 0 Mal 1 Byte (also nichts) ab der Position 1073741824 und erzeugt somit ein 1GB große Sparse Datei ohne jeglichen Inhalt. Man erkennt es eindeutig an der scheinbaren Differenz zwischen Size und der Anzahl der benutzen Blocks mit stat

Achtung:

An solchen sparse Dateien ist schon mancher Adim zB bei Backups verzweifelt, man kann ein solches File meist schon durch umkopieren mit cp in ein normales Files umwandeln.

Erzeugen einer Datei gefüllte mit Zufallszahlen

Als Quelldatenstrom nutzen wir dazu unter Linux /dev/urandom (nicht /dev/random , das dauert sonst viel viel zu lange und bringt auch nur das selbe Ergebnis)

robi@LINUX:~/test> dd if=/dev/urandom of=file.zufall bs=1M count=1024
1024+0 Datensätze ein
1024+0 Datensätze aus
robi@LINUX:~/test> hexdump -C file.zufall | more
00000000  60 b2 03 a4 f5 13 46 d0  25 a4 f2 09 1c 31 9f 3f  |`².€õ.FÐ%€ò..1.?|
00000010  17 b0 8e 32 af a0 87 67  cf 87 2c 4f 6d 92 de 4d  |.°.2¯ .gÏ.,Om.ÞM|
00000020  38 3c a2 29 58 09 fd b7 ........
.......

Als Größe wurde hier wieder wie schon oben 1GByte festgelegt. Mit hexdump haben wir gleich mal hineingeschaut, ob auch alles schön zufällig ist. ;-)

Erzeugen einer Datei mit typischen Eigenschaften und genau definierter Länge

Die unterschiedlichen Dateien haben unterschiedliche Eigenschaften zB beim Komprimieren. ZB. Zufallsdateien lassen sich überhaupt nicht komprimieren, Dateien mit lauter Nullen dagegen extrem, Logdateien sehr gut, Textdateien auch noch gut, aber Binärdateien nicht besonders gut. Wenn wir jetzt so eine Datei mit solchen typischen Komprimierungseigenschaften zu Testzwecken benötigen, dann können wir und mit dd eine solche mit genaue definierter Länge erzeugen.

Als Beispiel wollen wir hier eine genau 5MByte große Datei aus einigen Bilddateien erzeugen.

robi@LINUX:~/test> ls -l bild*.jpg
-rw-r--r--  1 robi users 277960 2007-06-29 22:34 bild0.jpg
-rw-r--r--  1 robi users 312872 2007-06-29 22:48 bild10.jpg
-rw-r--r--  1 robi users 120061 2007-06-29 22:08 bild1.jpg
-rw-r--r--  1 robi users 164171 2007-06-29 22:10 bild2.jpg
-rw-r--r--  1 robi users 179737 2007-06-29 22:13 bild3.jpg
-rw-r--r--  1 robi users 173341 2007-06-29 22:13 bild4.jpg
-rw-r--r--  1 robi users 165532 2007-06-29 22:14 bild5.jpg
-rw-r--r--  1 robi users 161892 2007-06-29 22:16 bild6.jpg
-rw-r--r--  1 robi users 126340 2007-06-29 22:17 bild7.jpg
-rw-r--r--  1 robi users 125396 2007-06-29 22:19 bild8.jpg
-rw-r--r--  1 robi users 289134 2007-06-29 22:21 bild9.jpg
robi@LINUX:~/test> cat bild*.jpg bild*.jpg bild*.jpg bild*.jpg | dd of=file.bild bs=1024K count=5 
5+0 Datensätze ein
5+0 Datensätze aus
robi@LINUX:~/test> ls -l file.bild
-rw-r--r--  1 robi users 5242880 2007-06-30 00:40 file.bild

Unsere Bilddateien haben zusammen nicht ganz 2 MB Größe. Wir Nutzen desshalb cat , um die Dateien aneinander zu hängen, und da die Gesammtgröße aller Dateien nicht ausreichen würde, haben wir sie einfach durch "bild*.jpg bild*.jpg bild*.jpg bild*.jpg" mehrere Male angegeben, (4 Mal sollte dann hier dicke reichen). (wenn man hier bei anderer Gelegenheit einmal zu viele Dateien dazu verwenden müsste, könnte eventuell die Bash einen Fehler bringen, zu viele Argumente, dann kann man auch schrittweise vorgehen)
Den so erzeugten Datenstrom von cat leiten wir per Pipe an dd weiter und mit "bs=1024K count=5" erzeugen wir dann ein genau 5MB großes File daraus, die typische Eigenschaften einer solchen JPEG Bilddatei hat, obwohl sie selbst kein (ein fehlerbehaftes) Bild ist.

dd auf Partitionen und ganze Festplatten anwenden

Allgemeine Bemerkungen und Warnungen

Was passiert wenn wir mit dd auf eine Partition oder einer Festplatte zugreifen?

• Die Byte werden alle sequentiell von der Festplatte gelesen. Dabei werden nicht nur die Inhalte der Dateien, sondern auch die Verwaltungsdaten und die Struktur der Partitionen und der Filesysteme mit gelesen, Ebenfalls mitgelesen werden natürlich auch derzeit unbenutzte- und leere Böcke, und Blöcke die derzeit zu gelöschten Dateien gehören. Die gesamte Partition oder Festplatte wird also Byte für Byte gelesen und so gegebenfalls auch Byte für Byte kopiert.

• dd greift dabei direkt auf die Festplatte zu, also unter Umgehung des Cache der Filesysteme und des Swap. Das Filesystem bekommt das auch gar nicht mit. Wir sollten aus diesem Grunde auch für dd eine geeignete Blockgröße für die Zugriffe angeben (oder mit den default 512 Byte leben). Es ist also keinesfalls immer sichergestellt, dass zu jedem Zeitpunkt wirklich das mit dd gelesen wird, was auch wirklich im Filesystem in diesem Moment aktuell ist.

• Werden Filesysteme mit dd kopiert die aktuell noch readonly gemountet sind, dann ist das Ergebnis ein Image von diesem Filesystem das nicht sauber ausgehängt ist. Bevor wir es mounten können, muss erst ein fsck gemacht werden.

• Werden Filesysteme mit dd kopiert die aktuell noch read-write gemountet sind, dann muss vor dem mounten des Images oder der Kopie bei Jounalfilesystemen ein kompletter Filesystemcheck gemacht werden. Ansonsten wird bei fsck nur das Journal abgearbeitet ( die Daten im Journal sind aber weder aktuell noch wirklich gültig und zutreffend) und entstandene Inkonsitenzen und Fehler werden nicht behoben. Solche Fehler und Inkonsitenzen entstehen, da dd ein Filesystem nicht innerhalb eines Bruchteiles von Sekunden lesen kann, sondern dazu einige Minuten oder gar Stunden benötigt. In dieser Zeit arbeitet aber der Cache vom Filesystem ganz normal weiter und ändert auch den Inhalt auf der Platte. Wird jetzt zB. während dd eine Partition ließt, ein Cronjob gestartet der die Logdateien großflächig umorganisiert. Dann kann es natürlich sein, das bestimmte Blöcke von dd schon verarbeitet sind, die später jedoch ungültig werden oder durch andere Blöcke ersetzt werden die dd erst dann ließt wenn sie schon geändert sind. Es ist also durchaus möglich, das selbst nach einem kompletten Filesystemcheck eines so entstandenen Images einige Dateien fehlen, oder einfach einen falschen Inhalt haben, oder im Extremfall, das das Filesystem so defekt ist, das es nur unter enormen Datenverlust wiederhergestellt werden kann. Besonders gefährlich wird das, wenn man bei einem Filesystemcheck nur das Journal abarbeitet, und dann ganz normal unwissentlich mit einem strukturdefektem Filesystem weiterarbeitet. Man denkt alles in Ordnung, und plötzlich geht irgendwas nicht richtig oder es geht gar nichts mehr. Jetzt kann ein kompletter Filesystemcheck richtig böse Sachen aufzeigen.

• Zu den Verwaltungsdaten auf den Festplatte und Partitionen gehören natürlich auch die Partitionstabellen und gegebenenfalls Bootloader und auch Kennungs- Zustands- und Verwaltungsdaten von Softwareraid oder Virtuellen Laufwerken, vom Rechner als eindeutig gedeutete Filesystemkennungen, eventuell auch dem Filesystem bekannt gemachte defekte Blöcke. Werden diese Daten auf andere Festplatten kopiert und es sich dabei nicht um eine identischen Festplatte handeln sollte, die die ursprüngliche Festplatte ersetzen soll, sollte man sich hier sehr genau überlegen was man da macht, oder hin und wieder auch einmal mit einer Überraschung beim nächten Bootvorgang rechnen.

Festplatte testen durch Lesen

• Hin und wieder muss man mal eine Festplatte testen, ob denn diese überhaupt noch richtig angesprochen werden kann.

dd if=/dev/hdb of=/dev/null bs=4K count=1000

dieser Test dauert nur eine Sekunde, reicht aber aus, um zu erkennen ob die Platte überhaupt noch was tut.

• Hat man viele SCSI-Platten im System, dann kann es hin und wieder vorkommen, man muss unbedingt wissen. welche physikalische Platte ist zB. /dev/sdf
  

solange die Platte bisher nicht mit Fehlern oder Totalausfall geglänzt hat:

dd if=/dev/sdf of=/dev/null bs=8K count=100000

dieser Test könnte so 30 bis 60 Sekunden laufen, in dieser Zeit sollte die Aktivitäts-LED dieser Platte permanet an sein. Sobald der Befehl beendet ist, oder mit "STRG + C" abgebrochen wird, ist sie aus, oder flackert sporatisch wieder wie eventuell die anderen auch. Wenn diese Platte aber Probleme bereitet, dann ist es meist besser diese nicht direkt anzusprechen, sondern die benachbarten Platten , hier im Beispiel also /dev/sde und /dev/sdg, die Platte zwischen diesen Beiden sollte dann die gesucht /dev/sdf sein.

• Sollte es Busprobleme geben, zB wegen defekten oder ungeeigneten Kabel oder falschen DMA-Einstellungen oder Unverträglichkeit von 2 Geräten am Bus, kann man Lesetests über mehrere Minuten machen, gegebenenfalls über mehrere Geräte am selben Kontroller. Dabei die /var/log/messages auf Einträge beobachten. (Bei IDE Geräten: Fehler- und Befehlsbeschreibung hdparm)

• Steht eine Platte in Verdacht auf sporatische oder gelegentliche Leseprobleme, und ist der erste kurze Ansprechtest erfolgreich gewesen, kann man einmal die gesamte Platte oder die entsprechend fehlerverdächtige Partition auslesen. (Achtung kann eventuell die Performance des Systems über einen längeren Zeitraum sehr negativ beeinflussen, je nachdem welche Filesysteme sich auf dieser Platte befinden)

dd if=/dev/hda of=/dev/null bs=4k

kommt es zum Abbruch des Befehles wegen Lesefehler, dann wird es allerhöchste Eisenbahn sich eine Reserve Platte zu besorgen, und das letzte Backup auf Vollständigkeit zu prüfen. Eventuell gleich noch ein Backup dieser Platte versuchen. Einige Backup-Programme haben auch Optionen die bei Lesefehlern nicht gleich abbrechen, sondern versuchen erstmal noch weiterzumachen. Fehlerhafte Dateien oder Abschnitte werden übersprungen.

Achtung:

Sollte die Elektonik des Kontrollers oder die Elektronik der Festplatte der Verursacher der zu untersuchenden Fehler gewesen sein, dann kann es in Einzelfällen dazu führen, dass der dd-Befehl hängen bleibt, aber weder eine Fehlermeldung ausgibt, noch sich mit kill beenden läßt. Mit top oder ps ist der Prozessstatus "D" beim dd-Prozess zu erkennen. Hier einfach erst einmal einige Minuten warten, eventuell greift doch noch ein Befehlstimeout oder eines der Geräte am Bus forciert einen Busreset. Wenn dem nicht so ist und es nach 15 Minuten keine Änderung ergeben hat, dann hilft hier dann oft nur noch ein reboot, um den hängenden dd-Befehl loszuwerden.

der MBR und dd

mit dd den Master Boot Record auf Festpatten lesen und schreiben

Auf sehr vielen Seiten im Internet wird aufgezeigt wie man mit dd den MBR (Master Boot Record) einer Festplatte sichern und wieder zurückschreiben kann. Was auf vielen Seiten allerdings meistens fehlt, sind genauere Erklärungen dazu, was sich dort alles befindet, damit man besser abschätzen kann, unter welchen Bedingungen man was damit genau machen kann oder besser lassen sollte, und welche Alternativen es für einzelne Bereiche bzw. Abschnitte gibt. Aus diesem Grunde werden wir das hier einmal etwas ausführlicher behandeln.

Anmerkung:

Wir sprechen im Weiteren hier von BIOS-basierten Computern der x86-Architektur, es gibt durchaus bei anderen Betriebssystemen und Plattformen auch noch ganz andere Architekturen und Strukturen, aber wir bleiben hier mal bei der typischen IBM-kompatiblen PC-Technik, mit der wohl bis auf ganz wenige Ausnahmen hier alle ihr Linux installiert haben werden

Sichern könnte man den MBR von zB der Festplatte /dev/hda folgend:

dd if=/dev/hda of=/PATH/DATEI bs=512 count=1

Zurückspielen dieser Datei wieder in den MBR dieser Festplatte

dd if=/PATH/DATEI of=/dev/hda bs=512 count=1

Sich nur den Inhalt einmal hexadezimal anschauen, kann man zB so hier

dd if=/dev/hda bs=512 count=1 | hexdump -C | more 

Wie wir aus den Befehlen herauslesen können, es handelt sich hier beim MBR um die ersten 512 Byte der Festplatte. Wie der Name es schon vermuten läßt, es hat irgend etwas mit dem booten zu tun. Und in der Tat, beim Start des Rechners, schaut der BIOS welches Medium soll ich booten, und dann läd er von diesem Medium genau diese 512 ersten Byte. Findet er darin etwas für ihn interessantes, dann versucht er damit den Bootvorgang zu starten. findet er nichts interessantes, dann schaut er ob noch weitere Medien konfiguriert und vorhanden sind, von denen er booten soll, und versucht dort sein Glück. Findet er dabei gar nichts brauchbares, dann kommt die Fehlermeldung, er hat kein Betriebssystem zum booten gefunden.

Was befindet sich nun in diesen ersten 512 Byte einer Festplatte?

Wir werden das hier mal von hinten aufrollen. ( Das erste Byte bezeichnen wir als Byte 0 demnach umfasst der Bereich den wir untersuchen Byte 0 bis Byte 511 )

1. Byte 510 (0x1fe) und Byte 511 (0x1ff) enthalten eine Kennung (auch MBR-Signatur genannt) die dem BIOS mitteilt, das was hier im MBR steht, ist für dich ein gültiger MBR oder nicht gültig. Der BIOS erkennt den MBR als gültig nur dann an, wenn dort 0x55 0xAA steht. Bei nicht bootfähigen Platten darf hier auch etwas anderes stehen, allerdings wurden schon BIOSe erwischt, die vorsichtshalber eine solche Platte dann gleich mal mit geringer Geschwindigkeit bedient haben, so dass hier prinzipiell immer dieser Wert stehen sollte, wenn eine gültige Partitionstabelle vorliegt.
2. Die 64 Byte, Byte 446 bis Byte 509 (0x1be bis 0x1fd) dort befindet sich prinzipiell auf jeder Festplatte immer die Partitionstabelle für die Partitionen 1 bis 4 . Pro Partition 16 Byte das ganze 4 Mal. Nicht definierte Partitionen sind mit NULLEN gefüllt.
3. Die Byte 444 (0x1bc) und Byte 445 (0x1bd) enthalten den Wert 0x0000 und dienen nur zur Trennung und dem Schutz der einzelnen Bereiche
4. Der Bereich von Byte 0 bis Byte 443 (0x000 - 0x1bb) ist reserviert für einen Bootloader ( wobei in einigen Windowssystemen noch ein Teilbereich davon fest definiert ist Byte 440-443 (0x1b8 -0x1bb). hier befindet sich eine Disk-Signatur, mit deren Hilfe zB die Zuordnung zu den Laufwerksbuchstaben vorgenommen wird.) Es sind also in diesem Bereich maximal 444 Byte für einen Bootloader möglich, Es handelt sich dabei um ein kleines mittels Assemblerprogrammierung geschrieben ausführbares Programm. Dieser Bereich kann aber durchaus auch leer sein (alles NULL) es können aber auch zB. Bootloader dort installiert sein, die bei Versuch diesen zu starten nur ausgeben, dass das Medium nicht bootfähig ist, oder Bootloader die nur einen anderen Bootloader von einer der Partitionen laden und diesen dann starten oder nur ein Auswahlmenu bringen, um daraus dann auf andere Bootloader zu verzweigen. Aber auch Bootvieren sind dort möglich. Wie die einzelnen Bootloader arbeiten ist recht unterschiedlich. Jedoch können sie nur auf die wenigen Funktionen des BIOS zugreifen und ihre Aufgabe ist es, damit den Betriebssystemkern auf der Platte in den Arbeitsspeicher zu laden und zu starten, oder ein oder mehrere (größere) Programme zu laden, die genau das können. In vielen Bootloadern ist desshalb genau hinterlegt oder festgeschrieben, in welchen pysikalischem Bereich (genauer Block) der Festplatte sich die Datei befindet, die als nächstes geladen werden soll, denn die komplizierten Strukturen von Filesystemen würden natürlich in diese 444 Byte nicht hinein zu programmieren sein.

Schlußfolgerungen für das kopieren des MBR mittels dd

Daraus ergeben sich jetzt eine ganze Reihe von Beschränkungen für das so schön einfache kopieren des MBR wie es oben angegeben ist. Prinzipiell gilt, es wird mit dd direkt in einen sehr sensieblen Bereich der Festplatte hineinschreiben, und dabei kann keinerlei logische Überprüfung vorgenommen werden. Solche Vorgehensweisen und Methoden sollten möglichst immer erst das letzte Mittel der Wahl darstellen.

• Das kopieren eines solchen MBR (512 Byte) auf die selbe Platte bringt nur Erfolg, wenn sich in der Zwischenzeit weder die Partitionstabelle noch der physikalische Ort (Block auf Festplatte) der Dateien geändert hat, die dieser Bootloader über den BIOS laden soll.
• Das kopieren eines solchen MBR (512 Byte) auf eine andere Platte macht nur dann Sinn, wenn es sich auch wirklich um eine identische Platte handelt. (Ausnahme wenn wir eine Platte durch eine größere Platte ersetzen müssten, und wir die Differenz sowieso nie benutzen möchten)
• Baugleiche Platten könnten ( ist im PC-Bereich ehr die Ausnahmen) logisch anders organisiert sein, da die Festplattengeometie wie wir sie sehen nicht mit dem physikalischen Aufbau der Platte gleich ist und die Platte das selbst verwaltet. Solche Differenzen könnten in Ausnahmefällen schon beim Erwerb gleicher Platten aus unterschiedlichen Bezugsquellen vorliegen, oder irgendwann einmal über Software manuell geändert worden sein. Es ist auch nicht gänzlich auszuschließen, daß der eine oder andere Raidkontroller durchaus auch einmal so eine logische Plattengeometrie geändert haben könnte. Ein kopieren einer Partitionstabelle mit andere logischer Geometie könnte uU. durchaus dann zu defekten oder ungültigen Partitionstabellen führen.
• Wenn wir 512 Byte anfassen, sollten wir bedenken, das damit immer die Partitionstabelle der Partitionen 1-4 enthalten ist. Die logischen Partitionen jedoch nicht, und somit beim neu Beschreiben des MBR sogar verloren gehen können.
• Die Partitionstabelle wird in der Regel nur beim Start des Rechners oder bei speziellen Komandos von Linux neu ausgelesen. Wird mit dd die Partitionstabelle geändert, dann arbeitet der Kernel nach wie vor nach der alten Partitionstabelle weiter. Wird also eine komplette Platte überschrieben, und anschließend eine Partition versucht zu mounten, dann wird der Kernel das Filesystem an einer eventuell falschen Stelle suchen.
• Im Windowsumfeld könnten unter Umständen geklonte MBR (und somit enthaltene gleiche Disk-Signatur auf unterschiedlichen Platten) im gleichen System zu instabilem Betrieb oder Bootproblemen führen.

Anwendungsbeispiele und Alternativen

Den Bootloader sollte man nach dem kopieren oder verschieben der Rootpartition am besten wieder mit den dafür vorgesehen Tools neu schreiben. Siehe dazu grub-install oder Grub-Install via "chroot" und Knoppix hier im Wiki, bei LILO gilt das analog, immer am Besten mit lilo wieder installieren, hilfreich sicher auch Lilo wieder herstellen hier im Wiki
Die Partitionstabelle sollte man wenn möglich immer komplett (also auch die eventuellen logischen Partitionen) sichern und gegebenenfalls zurückschreiben oder clonen. Obwohl es nicht unmöglich ist, auch die logischen Partitionen mittels dd zu kopieren und wieder zurückzuschreiben, ist es so kompliziert, dass darauf verzichtet wird, es an dieser Stelle vorzustellen. Statt dessen soll hier auf den Artikel Partitionstabelle sichern und wiederherstellen verwiesen werden. Dort wird erklärt wie man die komplette Partitionstabelle mittels des Befehles sfdisk einfach und sicher speichern und wieder zurückschreiben kann.

Für die jetzt nur noch ganz wenigen verbleibenden Ausnahmen hier einige Beispiele (auf eigenen Gefahr) wie man mittels dd im MBR bestimmte Dinge erledigen kann.

Wichtig:

nach jeder geschriebenen Manipulation an der Partitionstabelle mittels dd wird der Kernel so lange mit der alten Partitionstabelle weiterarbeiten, bis der Rechner wieder neu gebootet wurde, oder wir dem Kernel explizied dazu gezwungen haben die jetzt neue Partitionstabelle von der Platte neu einzulesen. Dazu darf keine Partition dieser Platte mehr gemountet sein und auch kein Swap auf dieser Platte aktiv, dann sfdisk -R /dev/PLATTE

Bootloader als Datei sichern und zurückschreiben

dd if=/dev/hda of=/PATH/DATEI bs=1 count=444
dd if=/PATH/DATEI of=/dev/hda bs=1 count=444

Bootloader mit Nullen überschreiben

dd if=/dev/zero of=/dev/hda bs=1 count=444

Partitionstabelle (nur Partitionen 1 bis 4) hexadezimal anschauen

dd if=/dev/hda bs=1 count=66 skip=446 | hexdump -C

Partitionstabelle (nur Partitionen 1 bis 4) als Datei sichern /zurückschreiben

dd if=/dev/hda of=/PATH/DATEI bs=1 count=66 skip=446
dd if=/PATH/DATEI of=/dev/hda bs=1 count=66 seek=446

Partitionstabelle (nur Partitionen 1 bis 4) auf andere Platte direkt kopieren (hda -> hdb)

dd if=/dev/hda of=/dev/hdb bs=1 count=66 skip=446 seek=446 

Partitionstabelle löschen

dd if=/dev/zero of=/dev/hda bs=1 count=64 seek=446

Windows Disk-Signatur mit Nullen überschreiben

dd if=/dev/zero of=/dev/hdb bs=1 count=4 seek=440

MBR-Signatur wieder mit 0x55 0xAA beschreiben ( MBR wieder gültig machen)

echo -en "\x55\xaa" | dd of=/dev/hda bs=1 count=2 seek=510

einzelne Partitionen und ganze Platten mit dd

Das kopieren, klonen, oder als Image ablegen und wieder zurückschreiben von einzelnen Partitionen und ganzen Platten mittels dd, so wie es in unzähligen Beiträgen beschrieben ist, ist und bleibt eine riskante Angelegenheit, solange man sich nicht bewußt ist, was man da eigentlich genau macht.
Es werden genau genommen jedes Byte der Festplatte oder der Partition genau so gelesen, wie sie derzeit auf der Platte gespeichert sind, und wieder zurückgeschrieben, wie sie zum jeweiligen Zeitpunkt des Lesens auf der Festplatte vorhanden waren. (siehe auch die allgemeinen Warnungen) Somit benötigt man ein zweites Medium, das auch groß genug ist, diese Daten auch wirklich aufzunehmen, den ein Image einer 200GB Festplatte ist nun einmal 200GB groß, auch wenn nur 10% davon mit Dateien belegt sind. Pinzipiell ist es demnach umso interessanter, je kleiner die Festplatte oder die Partition ist, und um so mehr Daten darauf aktuell abgelegt sind. Solange man ein solches Image dann auch wieder auf die gleiche Festplatte oder in die gleiche Partition zurück schreibt, ist das auch relativ ungefählich. Wird eine größere Festplatte zum zurückspielen benutzt, dann wird die größere Festplatte auf die Orginalgröße der ursprünglichen Festplatte "herunterkonfiguriert", ein Benutzen des übrigen unbenutzten Festplattenplatzes ist erst einmal ausgeschlossen und Versuche diesen doch noch nutzbar zu machen, sind sehr riskant für die Daten auf dieser Platte. Eine zu kleine Festplatte würde dann mindestens ein unvollständiges Filesystem ergeben, das sich gar nicht mounten läßt. Das selbe gilt für Partitionen analog. Sehr gefährlich ist zB. ein zurückschreiben von erweiterten und logischen Partitionen, wenn sich die Partitionstabelle geändert hat, bzw auf eine andere logische oder erweiterte Partition. Hierbei ist es durchaus möglich, das nach dem nächsten booten ein Teil der Daten auf der Platte gar nicht mehr aufzufinden sind.

Beispiele Clonen, Backup und Sicherung

Es gilt, möglichst alle Filesysteme ungemountet auslesen, wo das nicht möglich ist, zumindestens Readonly gemountet auslesen und dann auf das Image einen Filesystemcheck machen.

einzelne Partition als Image ablegen / Image temporär mounten / zurückschreiben

# dd if=/dev/hda2 of=/PATH/DATEI.IMAGE bs=8K
# mount -o loop /PATH/DATEI.IMAGE /mnt      # eventuell weitere Mountoptionen notwendig
# dd if=/PATH/DATEI.IMAGE of=/dev/hda2 bs=8K

Filesystemtype und Zustand eines Images ermitteln/korrieren (Konsolauszug)

LINUX:/ # file DATEI.IMAGE
DATEI.IMAGE: Linux rev 1.0 ext2 filesystem data (mounted or unclean)
LINUX:/ # fsck /PATH/DATEI.IMAGE  # evtl. weitere Optionen notwendig ; kompletten Path des Images
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
/PATH/DATEI.IMAGE was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/PATH/DATEI.IMAGE: 72/16632 files (12.5% non-contiguous), 24776/66432 blocks
LINUX:/ # file DATEI.IMAGE
DATEI.IMAGE: Linux rev 1.0 ext2 filesystem data

einzelne Partition auf eine Festplatte mit identischem Partitionstabelle kopieren

# dd if=/dev/hda2 of=/dev/hdb2 bs=8K

ganze Festplatte als Image ablegen / zurückschreiben

# dd if=/dev/hda of=/PATH/DATEI.IMAGE bs=8K
# dd if=/PATH/DATEI.IMAGE of=/dev/hda bs=8K

man kann von einem solchem Image auch einzelne Partitionen temporär gemounten, dabei muss für das mount der jeweilige Offset benutzt werden.

Festplatte auf einen andere Festplatte clonen

# dd if=/dev/hda of=/dev/hdb bs=8K

Problem Komprimierung von dd-Image

Hin und wieder besteht die Notwendigkeit ein solches Image zu komprimieren, weil eben nur wenige wirkliche Daten auf der Platte/Partition liegen. Dabei wird man auf das Problem stoßen, das kann recht gut funktionieren aber muss nicht zwangsläufig. Das liegt dann meistens an den zur Zeit nicht benutzten oder gelöschten Datenblöcken. Sind diese zum großen Teil nicht oder nicht richtig komprimierbar, dann wird man auch wenig Erfolg bei der Komprimierung der gesamten Platte/Partition haben.
Nachfolgend eine Möglichkeit wie man die leeren/unbenutzten Datenblöcke einer Partition sehr gut komprimierbar machen kann, ohne das die richtigen Daten dabei beschädigt werden. Man legt einfach neue "NULL"-Dateien an bis das Filesystem fast voll ist, danach löscht man sie wieder. Wir machen uns hier zum Vorteil, dass ein normaler User im Normalfall auf LINUX-Filesystemen nur bis zu 95% voll auf ein Filesystem schreiben kann. Ausnahme natürlich wenn Disk Quota eingerichtet ist.

Als root in das Filesystem ein neues Verzeichnis anlegen und für Schreibrechte des Users sorgen

# mkdir /PATH/test
# chmod a+w /PATH/test

Danach als User folgendes Script ausführen

#!/bin/bash
VERZEICHNIS=/PATH/test

dd if=/dev/zero of=/tmp/file.null count=1024 bs=1K 2>/dev/null
echo "anlegen von Dateien bitte warten" 
for i in {a..z}{a..z}{a..z}
 do
   for j in {0..9}{0..9}{0..9}{0..9}
   do
      NAME=${VERZEICHNIS}/leer$i$j
      cp /tmp/file.null $NAME 2>/dev/null || break 2
   done
done
rm /tmp/file.null

Als VERZEICHNIS ist hier genau das eben von root angelegte Verzeichnis anzugeben. Je nach Größe und Benutzungsgrad des Filesystems kann das schon seine Zeit dauern. Es werden 1MByte große Dateien in diesem Verzeichnis angelegt.
Ist das Script fertig, muss erst einmal der Cache des Filesystems die Daten alle auf Platte schreiben, also entweder abwarten oder wenn möglich das Filesystem umounten und anschließend wieder mounten. ( Das ist vor allem wichtig bei sehr kleinen Filesystemen die eventuell sogar komplett im Speicher gecacht sein könnten.)

Root kann jetzt das komplette Verzeichnis wieder löschen (Achtung "rm *" im Verzeichnis wird meist wegen zu vieler Argumente nicht funktionieren)

rm -rf  /PATH/test

Jetzt muss erst einmal wieder der Cache das Filesystem neu mit der Platte abgleichen, also hier auch am Besten umount / mount (der sync Befehl hat hier erstaunlicherweise bei meinen Tests nicht immer das erhoffte Resultat gebracht)

Jetzt ist diese Partition bereit zum Erstellen eines effektiven komprimierten Images.

dd if=/dev/hda2 bs=4K | gzip > /PATH/DATEI.IMAGE.gz

Zurückschreiben könnte man dieses komprimierte Images zB.:

zcat /PATH/DATEI.IMAGE.gz | dd of=/dev/hda2 bs=4K 

Mit ganzen Platten geht das analog, nur sollte man für optimale Ergebnisse eben alle Filesysteme vorher "aufräumen".

Beispiel: dd nach einem Super-GAU im Filesystem

Konstruieren wir uns doch einmal ein Super-GAU Szenario

(Ähnlichkeiten mit realen Ereignissen oder Personen sind rein zufällig ;-) )

Beispiel: '

Nach monatelanger allnächtlicher Mühe ist die Doktorarbeit mit all ihren Texten, Bildern und Zeichnungen nun entgültig fertig. Korrektur ist gelesen, ist gut geworden, und man hat die Doktorwürden jetzt schon so gut wie in der Hand. Nur noch ausdrucken und fertig. Da man in den letzten Wochen leichtsinnigerweise kein Backup gemacht hat, man ist eben so optimistisch, es wird jetzt aber aller höchste Eisenbahn, dieses nachzuholen. Mit dem Kopf schon am überlegen ob wohl der Drucker auch noch genug Tinte hat, nur schnell noch ein paar alte temporäre Dateien löschen die nicht mit ins Backup brauchen. Doch was ist das jetzt für eine Fehlermeldung rm: cannot remove directory `./': Invalid argument und ls -l zeigt plötzlich auch nur total 0 ??? Der geschärfte Blick auf die Konsole läßt erkennen, die gesamte Doktorarbeit rekursiv gelöscht. Das Adrenalin schießt in den Kopf, wie war das nochmal mit reiserfs und gelöschten Dateien? - ein Aufschrei - ein Hechtsprung - den Kaltgerätestecker aus dem Rechner ziehen - alles Eins. Super-GAU komplett und morgen ist Abgabetermin.

Wird jetzt an dieser Stelle der Rechner hochgefahren und normal gestartet hat man eventuell genau einen Reparaturversuch wieder an seine gelöschte Doktorarbeit zu kommen. Misslingt dieser Versuch ganz oder teilweise, dürfen eventuell größere Teile ganz neu geschreiben werden. Wohl dem der in dieser Situation jetzt genau das richtige Howto findet.

Besser hier, eine große Festplatte suchen und zusätzlich anschließen. Den Rechner von CD booten und zu aller erst mittels dd ein Image der betroffenen Partition oder der gesamten Festplatte auf diese Platte erstellen. Erst dann einen normalen Boot versuchen oder mit der Reparatur der Filesysteme beginnen. Sollte der erste Versuch fehlschlagen, dann wieder das Image zurückspielen und das nächste Howto ausprobieren. Man kann so über das zurückschreiben des Images die haargenaue ursprünglich defekte Situation des Filesystems beliebig oft rekonstruieren und so seine Changen auf die Wiederherstellung der Daten bedeutend verbessern.

Beispiel: mit dd nach verlorenen Dateiinhalten suchen

Beispiel: '

Wir haben eine Textdatei verloren, an der wir in den letzten Tagen rumgebastelt haben. Alle bisherigen Versuche die Datei wiederzufinden waren ergebnisslos.

Sollte es sich um eine Textdatei, script, Quelltext oder ähnliches handeln, haben wir eine gute Change hier doch noch an den Inhalt heranzukommen, sollte sich dieser noch irgendwo in einem gelöschtem Datenblock befinden. Alles was wir benötigen ist die Paritition auf der sich das Filesystem befindet in der sich die Datei befunden haben muss, die ungefähre Größe dieser Datei in Zeilen, eine sehr markante Wortkombination innerhalb einer Zeile die nur in dieser Datei oder deren Kopien vorkommen kann, und eine etwaige Position dieses Suchbegriffes in Zeilen innerhalb der Datei.

Wir nehmen folgendes an:

1. Partition /dev/hda2
2. Größe der Datei 100-150 Zeilen
3. genaue Wortkombination im letztem Drittel "darf ich mir vormerken"

dd if=/dev/hda2 bs=4K | strings | grep -B 150 -A 100 "darf ich mir vormerken" > /tmp/gefunden.txt

Damit lesen wir mittels dd die Partition aus, strings entfernt aus diesem Datenstrom schon einmal alles was nicht nach druckbaren aussieht, grep durchsucht jetzt diesen Datenstrom nach dem Vorkommen der Wortkombination und wenn er eine solche gefunden hat, dann schreibt grep die Zeilen von 150 Zeilen davor bis 100 Zeilen danach in eine Datei Namens /tmp/gefunden.txt , werden mehrere solcher Wortkombinationen gefunden, dann auch die entsprechenden Bereiche aus diesen Blöcken.

Wenn sich also ein Datenblock auf der Festplatte befindet, der die genaue Zeilenwortkombination beinhaltet, dann werden wir den Textinhalt irgendwo innerhalb der gefunden.txt wiederfinden. Jedoch ohne eventuelle Leerzeilen, auch extrem kurze Zeilen (weniger als 4 druckbare Zeichen) sind verschwunden. Diesen Inhalt können wir aber immerhin jetzt aus gefunden.txt herauskopieren und wieder neu zu einer entsprechenden Datei formatieren.

mit dd Partitionen und Festplatten sicher löschen

Ein löschen ( besser ein überschreiben) von Partitionen und Festplatten mit dd ist ein weiteres beliebtes Anwendungsgebiet. Abzuraten jedoch bei Logischen Partitionen, hier könnten innerhalb der ersten 512 Byte Teile der Gesamt-Partitionstabelle überschrieben werden, und somit andere logische Partitionen nach dem nächsten reboot nicht mehr sichtbar sein. Siehe hierzu auch Wie eine Platte unwiederherstellbar und sicher loeschen

CD DVD und Floppy mit dd

Floppy Images mit dd

Der Eine oder Andere wird sie noch verstaubt in der Ecke habe, die gute alte 1,44er Floppy. Von den eventuell noch benötigten Floppys kann man aber auch mit dd Image erstellen und diese dann übersichtlich auf seiner Festplatte verwalten.

dd if=/dev/fd0 of=/PATH/DATEI.IMG bs=1440K

als Blockgröße kann man bei intakten Floppys gleich 1440 KByte nehmen, sollte die Floppy schon "faule Stellen" haben, dann ist 512 Byte angesagt. (Einen gravierenden Geschwindigkeitsvorteil konnte ich bei Tests jetzt unter Linux nicht ausmachen)

Bei Bedarf kann man dieses Image dann auch gleich temporär mounten

mount -o loop /PATH/DATEI.IMG /mnt

Die Auto-Option wird hier die meisten Filesysteme von Floppy automatisch erkennen, ansonsten noch mit Mountoptionen nachhelfen.

Wird wirklich einmal wieder eine dieser Image als Diskette zB als Bootdiskette benötigt, dann das Ganze wieder rückwärts.

dd if=/PATH/DATEI.IMG of=/dev/fd0 bs=512

Floppy die beim Lesen schon Lesefehler produzieren kann man trotzdem zu einem Image abziehen. Solange nur einige wenige Blöcke kaputt sind, und nicht gerade ein geziptes Tar darauf abgelegt ist, kann man oftmals noch das wirklich Wichtige benutzen.

dd if=/dev/fd0 of=/PATH/DATEI.IMG bs=512 conv=noerror,sync

Die Blockgröße hier zwingend 512 und die Option conv=noerror,sync sorgt dafür, das bei einem Lesefehler der entsprechende Block mit NULLen gefüllt wird, und dd bei diesem Lesefehler nicht abbricht. Es sind also alle intakten Blöcke hinterher an der richtigen Position und das Image läßt sich meist problemlos mounten, so das man in aller Ruhe und ohne nervige Lesefehler vom Floppylaufwerk, die defekten Dateien suchen kann.
Die Ausgabe von dd in diesem Fall ist auch so präzise, dass man genau die fehlerhaften Stellen (mit den jetzt NULLen im Image) aus dem Fehlerausgabe herauslesen kann. Somit könnte man auch mit hexdump schon mal nachschauen, ob es nicht doch nur die README erwischt hat.

CD DVD und dd

Es gibt eine ganze Reihe von CD- und DVD-Formaten, und es gibt allerlei Bemühungen, damit nicht unbedingt jeder mit solchen Scheiben machen kann, was er gerne möchte. Wir wollen das an dieser Stelle etwas unterstützen und hier nicht allzu tiefgründig werden, desshalb nur einige kurze Bemerkungen.

1. Mit einer Vielzahl dieser Scheiben könnte man bestimmt analog wie mit einer Floppy verfahren. Die Blockgröße innerhalb normaler Grenzen sollte bei den heutigen Laufwerken bei dd meist wenig bis keinen Einfluß auf die Lesegeschwindigkeit haben, fällt also oft erst beim Auftreten von Lesefehlern ins Gewicht.
2. Ein Mounten eines Images wie oben beschrieben, funktioniert nicht zwangläufig mit jedem Type von Scheibenimage.
3. Versucht nicht mit dd eine CD oder DVD zu brennen, dazu gibt es genügend Brenntools die auch die Kontrolle über die Brennerhardware haben.
4. Den Inhalt zB. einer Audio-CD oder eine Video-DVD muss man noch lange nicht aufgeben, nur weil der Player immer an der selben Stelle abbricht. Mit dd könnte man hier schon noch etwas ausrichten, aber dd ist zwar universell aber nicht speziell für solche Zwecke gemacht, und hier nicht unbedingt die allerbeste Wahl.

Bandlaufwerke und dd

Bei den Bandlaufwerken sind wir dort, wofür dd ursprünglich einmal gedacht war. Hier kann dd als "Schweizer Taschenmesser" seine Stärken voll auspielen. In den letzten Jahren hat sich jedoch die Hardware entschieden verbessert, aber dd ist in seinen Grundzügen immer noch das Alte. dd ist nicht in der Lage den Datenstrom im Speicher erwähneswert zu cachen, so wie man es für moderne Laufwerke mit ihrem enomen Daten- und Durchsatzhunger gerne hätte. Wer sich näher damit befassen möchte, Bandlaufwerke und LINUX gibt eine Überblick und stellt auch Alternativen vor. Dennoch für viele nicht alltägliche Problemchen kann man sich immer wieder auf dd verlassen, auch wenn man die Laufwerke damit nicht immer im optimalen Bereich ansteuern kann. Die Einsatzmöglichkeiten sind hier vielfältig und in Zusammenarbeit mit einigen Spezialtools kann man nach Art eines MacGyver schon mal das Unmögliche möglich machen.

Hier nur ein paar einfache Beispiele: (Voreinstellungen und Positionierungsbefehle für das Laufwerk lassen wir der Einfachheit halber bei der Vorstellung reiner Befehle weg, bei Konsolauszügen sind sie ansatzhalber enthalten)

Eine ganze Festplatte als Image auf ein Laufwerk sichern. / zurückspielen

dd if=/dev/hda of=/dev/nst0 ibs=8K obs=64K
dd if=/dev/nst0 of=/dev/hda ibs=64K obs=8K

Wir arbeiten hier also mit 8KByte mit der Festplatte aber mit 64KByte ( oder Größer Laufwerkstypeabhängig) mit dem Bandlaufwerk. Durch die Hardwarkomprimierung der meisten Bandlaufwerke ist das übrigens sehr Speichereffektiv, wenn wir wie oben beschreiben die ungenutzten Blöcke der Partitionen hin und wieder einmal NULLen. Das Image belegt dann oft nur unwesentlich mehr Platz auf dem Band wie eine Tarsicherung. Eine Zeiteinsparung erreichen wir hier in der Regel allerdings nicht, denn die ganzen Nullen müssen trotzdem über Kontroller und Bus zum Laufwerk transportiert werden.

Prinzipiell können wir auf diese Art mit dd jede Datei, jeden Datenstrom auf ein Band schreiben und auch wieder lesen. Wir können mit dd auch das auslesen was mit anderen Backupprogrammen geschrieben wurde, Wichtig nur beim Lesen, wir müssen die selbe Blöckgröße verwenden mit der geschrieben wurde. Was wir allerdings komplett verlieren, wenn wir Dateien auf ein Band schreiben, den Dateinamen und Zugriffsrechte und alles was dazu gehört. Ist ein dd Befehl fertig, wird ein EOF-Marke aufs Band geschrieben. Es käme also jede Datei als ein eigenes Filearchiv auf dem Band an. Das lohnt sich nur bei sehr großen Dateien, oder bei Dateien die schon selbst ein Archiv sind, wie folgendes Beispiel zeigt.

LINUX:/tmp # tar -cf ./test.tar /etc
tar: Removing leading `/' from member names
LINUX:/tmp # mtst -f /dev/nst0 rewind
LINUX:/tmp # mtst -f /dev/nst0 setblk 0
LINUX:/tmp # dd if=./test.tar of=/dev/nst0 bs=64K
348+1 records in
348+1 records out
LINUX:/tmp # mtst -f /dev/nst0 rewind
LINUX:/tmp #  tar -tvb 128 -f /dev/nst0 | more
drwxr-xr-x root/root         0 2007-07-16 20:08:35 etc/
drwxr-xr-x root/root         0 2006-06-01 14:21:44 etc/X11/
drwxr-xr-x root/root         0 2004-10-24 14:58:35 etc/X11/fs/
-rw-r--r-- root/root      2523 2004-04-06 04:27:19 etc/X11/fs/config
drwxr-xr-x root/root ....................
................

wir haben hier zum Test ein Tararchiv aus /etc erstellt und als Datei abgelegt, diese Datei dann auf das Band geschrieben und anschließend mit tar das Inhaltsverzeichnis direkt vom Bandarchiv ausgelesen. (Zu beachten hier, da wir mit dd mit 64 KByte geschrieben haben, müssen wir jetzt mit tar auch mit 64KByte zugreifen.)

Da wir nun alles mögliche auf ein Band schreiben könnten, stellt sich die Frage, woher erkenne ich an einem unbekannten Band, was darauf abgelegt ist und mit welcher Blockgröße geschreiben wurde. Sprich, welches Tool müßte ich mit welchen Optionen verwenden, um das Band überhaupt lesen zu können. Die Lösung bietet dd.
Nehmen wir ein Beispiel, wir bekommen ein Band von einem Freund, und dieser sagt, wir sollen und das einmal anschauen. Es sollte ein selbst geschriebenes Programm im Quelltext sein, soviel wissen wir, aber nicht mit welchem Programm es gesichert wurde, geschweige mit welcher Blockgröße geschrieben wurde.

LINUX:/tmp # mtst -f /dev/nst0 rewind
LINUX:/tmp # mtst -f /dev/nst0 setblk 0
LINUX:/tmp # dd if=/dev/nst0 of=/tmp/block.data bs=128K count=1
0+1 records in
0+1 records out
LINUX:/tmp # ls -l block
-rw-r--r--  1 root root 5120 Jul 16 18:57 block
LINUX:/tmp # file block.data
block.data: ASCII cpio archive (SVR4 with no CRC)

wir legen das Band ein, und lesen mittels dd und der größtmöglichen Blockgröße mit der Linux und das Laufwerk arbeiten würde, (hier im Beispiel ein EXABYTE Laufwerk das maximal 128KByte Blockgroße zulassen würde.) An der Ausgabe von dd erkennen wir, es wurde ein Block gelesen und als Datei abgespeichert der allerdings (erwartungsgemäß) nicht die 128KByte Größe erreicht hat.
mit ls können wir jetzt erkennen wie groß die Datei und somit unser erster Block auf dem Band war, genau 5120 Byte (also 10 x 512Byte).
mit file können wir jetzt auch noch Linux bemühen für uns herauszubekommen, was das für ein File sein könnte. file kann das aus dem Anfang einer Datei von sehr vielen Dateitypen erkennen. Den ersten Block der Datei, also den Anfang haben wir ja vom Band geholt, also setzen wir file darauf an. Als Ergebniss sehen wir, es würde mit cpio geschrieben und Blockgröße 5120 Byte (bei cpio der Defaultwert) geschrieben, eine genaue Formatbezeichnung hätten wir auch noch, wenn sie von cpio nicht selbst erkannt werden würde. Jetzt sollten wir alles wissen, um das Band auszulesen zu können.

Neben Dateien und Archiven können wir auch Datenstöme auf Band schreiben. Das könnten jetzt zB Debugtraces von irgendwelchen Befehlen oder Trace von Netzverbindungen sein. Niemand kann genau vorhersagen wie schnell solche Datenstöme riesige Ausmaße annehmen, und niemand kann vorhersagen was alles für unbrauchbare und uninteressante Meldungen jetzt mitgelogt werden. Statt also hier noch irgend welche Filter nachzuschalten (und damit und einem zusätzlichen Schreiben der Logdatei auf die Festplatte den Rechner jetzt noch unnötig weiter zu belasten) - wir haben doch ein Bandlaufwerk - also schreiben wir den gesamten Trace einfach auf das Band, egal wie lang er wird, da passt schon ordentlich was drauf. Angenommen der Tracelog kommt in der Befehlskette als Standardausgabekanal an, dann einfach nach dd weiterleiten und auf Band schreiben.

BEFEHL | AM_ENDE | DER-TRACELOG | dd of=/dev/nst0 bs=64K 

Befehl fertig, dann kann entweder der Stream vom Laufwerk jetzt auf diesem oder einem anderem Rechner mittels dd in eine Datei zurückgespielt werden, oder dabei gleich noch mit grep gefiltert werden, um nur das wirklich Wichtige auszuwerten. Hat der Filter nicht funktioniert oder müssen noch weitere Filter hinzugefügt werden, kein Problem, der Stream kann ja beliebig oft vom Band ausgelesen werden, wir müssen also nicht nocheinmal den ganzen "Versuchsaufbau" rekonstruieren.

Wir müssen dabei auch nicht immer nur das Ende einer Kette anzapfen. Zapfen wir doch mal eine mittels Pipe verbundene Befehlskette in der Mitte an, genau dort, wo der dickste Datenstrom anliegt, und schreiben diesen Datenstrom parallel zur normalen Befehlsverarbeitung aufs Band.

Wir nehmen dazu einmal das Beispiel von vorhin, als wir auf der Platte nach verlorenen Dateiinhalten gesucht haben, und schreiben parallel dazu gleich noch das komplette Image dieser Partition auf das Band. Somit haben wir abgesichert, wird der von uns gesuchte Block später überschrieben, und wir ihn vorher immer noch nicht gefunden haben, können wir ihn immernoch beim Durchsuchen des Bandimages finden.

LINUX:/tmp # mkfifo /tmp/pipe
LINUX:/tmp # mtst -f /dev/nst0 rewind
LINUX:/tmp # mtst -f /dev/nst0 setblk 0
LINUX:/tmp # dd if=/dev/sdb1 bs=4K | tee /tmp/pipe | strings | grep -B 50 -A 20 "Starker Schneefall" > /tmp/gefunden.txt &
[1] 6373
LINUX:/tmp # dd if=/tmp/pipe of=/dev/nst0 bs=64K
126504+0 records in
126504+0 records out
0+63252 records in
0+63252 records out
[1]+  Done     dd if=/dev/sdb1 bs=4K | tee /tmp/pipe | strings | grep -B 50 -A 20 "Starker Schneefall" >/tmp/gefunden.txt

Wir legen uns eine Named Pipe an. In der Suchbefehlskette duplizieren wir mittels tee den Datenstrom in Richtung dieser Pipe. Die gesamte Befehlskette schicken wir in den Hintergrund. Dort wird sie so lange untätig warten, bis jemand die Pipe zum lesen öffnet. Zum Lesen öffnen wir die Pipe dann mit dem nächsten dd Kommando und leiten die Ausgabe an das Laufwerk weiter. Wenn der dd Befehl beendet ist, ist auch unser Hintergrundbefehl beendet.

Die Pipe brauchen wir jetzt nicht mehr, die können wir löschen, aber schauen wir uns das Ergebnis an.

LINUX:/tmp # rm /tmp/pipe
LINUX:/tmp # ls -l /tmp/gefunden.txt 
-rw-r--r--  1 root root 4044 Jul 16 19:43 /tmp/gefunden.txt

wir haben eine Datei gefunden.txt und wirklich, wir haben auch etwas gefunden

LINUX:/tmp # mtst -f /dev/nst0 rewind
LINUX:/tmp # dd if=/dev/nst0 of=/tmp/test.img bs=64K
0+63252 records in
0+63252 records out
LINUX:/tmp # file /tmp/test.img
/tmp/test.img: Linux rev 1.0 ext2 filesystem data
LINUX:/tmp # fsck /tmp/test.img
fsck 1.34 (25-Jul-2003)
e2fsck 1.34 (25-Jul-2003)
/tmp/test.img: clean, 40/126976 files, 51084/506016 blocks
LINUX:/tmp # mount -o loop /tmp/test.img /mnt

Und wir können vom Band unser Partitionsimage lesen. Zum Test wird auch gleich noch einen Filesystemcheck gemachen und das mounten probiert.