Hinweis: Hier wird auf das Tool ddrescue eingangen. Es existiert auch ein ähnlich klingendes Tool dd_rescue mit fast identischem Zweck. Jedoch sollte dd_rescue nicht mehr verwendet werden, weil das Tool veraltet ist. Zudem ist ddrescue eine komplette Neuprogrammierung. Ausserdem ist es auf Geschwindigkeit und geringere Fehleranfälligkeit beim Auslesen der Festplatte, einer Partition oder einer Datei optimiert.
Noch ein Hinweis für openSUSE 11.2 Nutzer:
In der aktuellen openSUSE 11.2 nennt sich das Package ddrescue, beinhaltet jedoch das veraltete Tool dd_rescue. Diese Package sollte in naher Zukunft ausgetauscht werden. Aus diesem Anlass empfehle ich das Package ddrescue direkt über mein Repo zu beziehen und zu installieren. http://download.opensuse.org/repositories/home:/Freespacer:/ddrescue/
Nun kommen wir zu unserem Thema Partitionssicherung. Für diesen Zweck verwende ich das Tool ddrescue. Es erstellt von einer Partition bzw. auch von einer Datei eine 1:1-Kopie. Das Tool hat auch ein nennenswerten Vorteil: Bei einem Lesefehler bricht es nicht ab, sondern macht einfach weiter. Hier hat das ältere dd_rescue das Nachsehen und quittiert hierbei seinen Dienst.
Um eine Partition z.B. /dev/sda3 in ein Image z.B. /home/benutzer/sicherung.img zu sichern, geben wir ihm folgenden Befehl:
# ddrescue [options] inputfile outputfile [logfile] ddrescue /dev/sda3 /home/benutzer/sicherung.img
Jetzt können wir das Image ohne Probleme mounten. Es verhält sich so, als ob es eine echte Partition wäre. Man muss jetzt noch wissen, welches Dateisystem das Image hat. Und lässt sich mit folgendem Befehl schnell ermitteln:
# file [FILE...] file /home/benutzer/sicherung.img
Als Ausgabe habe ich beispielsweise:
sicherung.img: Linux rev 1.0 ext3 filesystem data (large files)
Hier erkennen wir, dass es sich um ein ext3-Dateisystem handelt und geben die Option -t ext3 mit. Falls es abweichen sollte, bitte anpassen. Man kann diese Option auch weglassen. Jedoch muss man damit rechnen, dass das Einhängen des Images evtl. fehlschlagen wird, weil er das Dateisystem nicht kennt.
Nun können wir das Image mit der Option -r als schreibgeschützt mounten. Man kann auch dieses Image ohne Schreibschutz mounten. Dann wäre es aber eine sehr schlecht Kopie und könnte evtl. ein bereits defektes Dateisystem noch mehr kaputt machen. Da sich die Daten zwangsläufig verändern können.
Zum Schluß haben wir noch eine Option -o loop und weisen damit dem mount-Befehl an, dass die lokale Image-Datei als Loop-Device ins derzeitige Dateisystem einbinden soll.
# Verzeichnis erstellen, in der wir das Image mounten wollen mkdir -p /mnt/sicherung # Image nur lesend mounten. mount -r -t ext3 -o loop /home/benutzer/sicherung.img /mnt/sicherung
Um das Image wieder auszuhängen, genügt folgender Befehl:
umount /mnt/sicherung
Wenn die echte Partition wie auch das Image einen Fehler im Dateisystem hat, kann man auch auf diesem Wege sehen, wie der Fehler im Image behoben wird und ob er überhaupt behoben werden kann. Das Diagnose-Tool für das Dateisystem nennt sich hier fsck und wird wie folgt aufgerufen (hier ext3, sonst bitte anpassen):
fsck.ext3 -f /home/benutzer/sicherung.img
Als Ausgabe könnte es in etwa aussehen:
e2fsck 1.41.9 (22-Aug-2009) Durchgang 1: Prüfe Inodes, Blocks, und Größen Durchgang 2: Prüfe Verzeichnis Struktur Durchgang 3: Prüfe Verzeichnis Verknüpfungen Durchgang 4: Überprüfe die Referenzzähler Durchgang 5: Überprüfe Gruppe Zusammenfassung sicherung.img: 700882/6561792 Dateien (3.0% nicht zusammenhängend), 17256532/26216064 Blöcke
Falls man die echte Partition total zerschossen und die Partitionstabelle bzw. die Superblocks teilweise zerstört hat. So kann man mit dem Tool TestDisk versuchen, diese Superblocks auf dem Image wiederherzustellen. Hier wird die original Partition gar nicht angefasst. Ob danach der Fehler behoben ist, kann man leider nicht garantieren, aber ein Versuch ist es Wert:
testdisk /home/benutzer/sicherung.img
Für openSUSE 11.2 Nutzer können TestDisk bequem über zypper installieren:
zypper in photorec
TestDisk startet und blendet das Image und dessen Größe ein. Hier gehen wir mit der Enter-Taste auf „Proceed“ und machen mit diesem Image weiter. Im nächsten Menü wählen wir mit den Pfeiltasten den Eintrag „Intel“ aus. Und zum Abschluß wählen wir dann das Menüpunkt „Analyse“ und lassen das Image nun analysieren.
Sobald TestDisk durchgelaufen ist und vielleicht ein paar Superblocks wiederhergestellt hat, kann man das Image nochmal mit fsck drüberlaufen lassen. Zum Schluß kann man das Image mounten und das Ergebnis begutachten.
Viel Glück und Erfolg.
Pingback: Windows 7 Setup erkennt Festplatten nicht mehr
Guten Morgen,
vielen Dank für den hilfreichen Artikel. Ich habe schon einige Artikel gelesen und habe gddrescue als Werkzeug meiner Wahl auserkoren. Jetzt bin ich Qualitätsmanager und wie sollte es anders sein, Windows-Nutzer und kein IT-Fachmann und finde einige Antworten zu offen fragen nicht.
Es wäre schön, wenn Sie mir helfen könnten.
Ich habe gestern bereits einen kurzen Test gemacht und eine LiveCD gestartet. habe mir mit Gparted die Laufwerke angeschaut und auch den Befehl ddrescue eingegeben. Allerdings fehlten parameter, was mir sofort um die Ohren gehauen wurde
Wie steuere ich, das das Logfile auf einen USB-Stick ausgegeben wird?
Wie starte ich den 2. Durchlauf mit anderen Parametern, z.B. nach ein paar Tagen?
Woher weiss ddrescue nach einem Neustart (z.B. nach einem Userabbruch, oder erfolgreichem ersten Durchlauf), wo das Logfile liegt?
Vielen Dank fürs lesen und ggf. einer Antwort.
Freundliche Grüße,
Christian Deserno
Hallo Christian,
besser wir duzen uns.
Ich muss dir leider eine Gegenfrage stellen. Wofür brauchst du ddrescue, wenn nicht für die Datenrettung? Was genau ist dein Szenario?
Gruß
Sebastian
Hallo Sebastian,
inzwischen habe ich mich durchgewurschtelt und bin bei der Sicherung. Auf die gestellten Fragen habe ich inzwischen Antworten gefunden.
Zu Deiner Frage. Die 2. Festplatte (nennen wir sie HDB) im Rechner, die nur für das Sammeln von Dateien vorgesehen ist, wurde sehr langsam. Kopieren unter Windows ging schleppend. Es war nicht zu erwarten, dass ich die Daten über normales Kopieren in angemessener Zeit auf einen intakten Datenträger übertragen konnte.
Als ich von ddrescue las, entschied ich mich für diese Methode, da die Fakten eindeutig waren. Nach den anfänglichen Problemen, die viel Zeit gekostet haben, kam die nächste Ernüchterung. Die Rettung läuft mit ca. 200 KB/s.
Als ich 172 GB gesichert hatte, musste ich etwas auf HDA nachschauen und habe die Platten umgeklemmt. Am nächsten Tag habe ich das Sichern fortgesetzt und etwas Entscheidendes vergessen. Ich habe HDA nicht entfernt und ab Position 172 GB von HDA auf HDC weitergesichert. Übertragungsrate 90 MB/s. Zuerst war die Freude gross, weil es plötzlich so flott ging, bis ich meinen Fehler am Ende des Sicherungsvorgangs bemerkte. In Ermangelung des Know Hows, habe ich wieder von Anfang an gestartet, von HDB auf HDC zu sichern, wieder mit dieser minimalen Datenrate von schwankend 500 – 200 KB/s.
Grüße,
Christian