Ext4magic: Inode - Directory - Journal - Installation - Zeit-Optionen - Tricks&Tipps - Manpage - Expert-Mode

Unter Expert-Mode versteht ext4magic eine Befehlsgruppe und speziellen und selten benötigten Funktionen für nicht ganz alltägliche Aufgaben. Damit sollen insbesondere Möglichkeiten zur Wiederherstellung von Daten bei beschädigten Filesystemen zur Verfügung gestellt werden.

Die Funktionen des Expert-Mode sind per default nicht aktiviert. Werden sie benötigt muss ext4magic wie folgt neu compiliert werden. Im Folgenden die Befehle um ext4magic mit Expert-Mode neu zu kompilieren.

make clean
./configure --enable-expert-mode
make
sudo make install

Inhaltsverzeichnis

Optionen des Expert_Mode

In Version 0.2.2 sind folgende Optionen im Expert-Mode verfügbar.

"-s blocksize" Damit kann die Blockgröße für das Filesystem übergeben werden

"-n blocknummer" Damit kann die Blocknummer der Kopie eines Superblockes übergeben werden.

beide Optionen müssen zusammen angegeben werden und zwar in der Reihenfolge "-s blocksize -n blocknummer" um ext4magic dazu zu bewegen ein Backup des Filesystem Superblocks zu benutzen. Diese Optionen werden dann benötigt, wenn der Superblock beschädigt ist.

"-c" Diese Option kann noch zusätzlich zu "-s blocksize -n blocknummer" gewählt werden. Hierbei wird ext4magic nicht automatisch nach dem Journal in der Inode 8 suchen, sondern die Journal Inode aus Daten des Superblocks recovern. Dieses wird dann notwendig, wenn die ersten Inodeblöcke defekt sind und damit auch die Inode 8. (das Journal mit der Inode 8 und die Inode 2 für das Rootverzeichnis befinden sich im ersten Inodeblock des Filesystems.)

"-D" diese Option ist optimiert um Dateien aus einem defektem Filesystem zu recovern. Es werden die Dateien aus noch vorhandenen Inodeblocks recovert. Soweit das Journal unbeschädigt ist, werden dabei anstatt von defekten Inodeblöcken eventuell vorhandene Kopien derselben aus dem Journal verwendet. Bei gleichzeitiger Benutzung der Option "-c" wird ein beschädigtes Journal erkannt, und versucht ohne das Journal möglichst noch alle unbeschädigten Dateien zu recovern. Diese Option ist insbesondere geeignet für das Recovern eines am Beginn oder Ende überschriebenen Filesystems.

In ihrer Gesamtheit sind diese 4 Optionen dazu bestimmt Filesysteme zu öffnen und die Daten daraus zu recovern, wenn der Filesystem Beginn beschädigt oder das Filesystem teilweise überschrieben wurde. Es werden die Dateien anhand noch vorhandener Filesystemdaten versucht wiederherzustellen. Wurde versehentlich ein neues Filesystem über das alte angelegt, und somit die Filesystemmetadaten nahezu komplett überschrieben, kann diese Option nicht helfen, da dann nur leere Filesystemdaten gefunden werden. Eine Ausführliche Beschreibung dieser Optionen und deren Verwendung im nächsten Abschnitt.

Zusätzlich zu diesen neuen Optionen ist ab der Version 0.2.2 noch die Option

"-Q" im Expert-Mode verfügbar. Diese high quality Option gab es schon in früheren Versionen von ext4magic. Unter optimalen Voraussetzungen kann mit dieser Option in Teilbereichen des Filesystems Fehler durch wiederverwendete Inodenummern oder wiederverwendete Dateinamen beim recovern verhindert werden. Sind die Voraussetzungen im Filesystemjournal nicht optimal, sind dagegen sehr schlechte Ergebnisse zu erwarten. Dieses hat vielfach zu Verwirrungen bei Usern geführt, was dann auch der Grund für eine Auslagerung dieser Option in den Expert-Mode war. Eine Beschreibung zu dieser Option befindet sich unterhalb von Tricks & Tips

Beschädigtes Filesystem mit fsck reparieren oder mit ext4magic recovern

Gelegentlich kann es vorkommen, dass ein Filesystem am Anfang beschädigt wird. Dort befinden sich sehr wichtige Daten ohne die das Filesystem nicht benutzt werden kann. Mount-Versuche werden sinngemäß mit Fehlermeldungen abgewiesen, "unbekanntes Filesystem" oder "Superblock defekt oder nicht gefunden". Eine mögliche Ursache für solche Fehler ist eine Beschädigung der Partitionstabelle. Bei beschädigten Partititonstabellen kann ext4magic nicht helfen. Hier sollte zB. TestDisk genutzt werden, um die Partitionstabelle wieder herzustellen. ext4magic geht davon aus, das der genaue Beginn der Partition sich nicht verändert hat, und auch die ursprüngliche Partitionsgröße noch vorhanden ist. Wurde am Beginn der Partition durch Konsol- oder Scriptunfälle oder ähnlichen das Filesystem beschädigt oder teilweise überschrieben, kann ext4magic helfen, solange noch große Teile der Filesystem Metadaten unbeschädigt sind
Betrifft eine solche Beschädigung wirklich nur den Anfang, dann sind alle oder die meisten Dateien des Filesystems noch unbeschädigt. Oftmals kann das Filesystem auch mit fsck in einem solchen Fall repariert werden. Ein Reparaturversuch mit fsck ist allerdings in diesem Fall etwas riskant, und sollte am Besten erst vorgenommen werden nachdem man vorsichtshalber eine 1 zu 1 Kopie des defekten Filesystems erstellt hat.

Nachteilig hier bei der Verwendung von fsck

fsck wird das Filesystem bei dem Reparaturversuch verändern, dieses kann sehr massiv sein.
es muss versuchen alle Ungereimtheiten und Fehler im Filesystems zu korrigieren und muss deshalb sehr penibel vorgehen.
es werden dabei hunderte oder tausende Fehlerausgaben oder interaktive Eingabeaufforderungen erscheinen, die man eigentlich nur alle mit "Yes" beantworten kann, also man das Programm am besten gleich mit der Option -y startet. Die Ausgaben sind nicht einfach zu verstehen und für den Laien nicht wirklich zu interpretieren. Erzeugen deshalb meist ein ungutes Gefühl, wenn sie am Bildschirm massenweise durchlaufen.
ein Probelauf mit der Option "-n" ist oftmals nicht wirklich hilfreich, da die Menge der Fehlerausgaben meist unübersehbar lang und wenig wirkliches Verständliches enthält und ein wirkliches Ergebnis zum überprüfen nicht entsteht.
ein einmal gestarteter Reparaturprozess sollte nicht auf halbem Weg aus irgend einem Grunde abgebrochen werden.
Es ist an Hand der laufenden Ausgaben nicht ersichtlich, ob und was wirklich funktioniert, ein Ergebnis wird man erst sehen wenn man anschließend das Filesystem mounten kann.
bei schweren massiven Fehlern ist die Wahrscheinlichkeit hoch, das fsck mitten in der Reparatur aufgibt, abbricht eventuell gar abstürzt. Eine Wiederholung des Reparaturversuches wird dann meist keine Verbesserung mehr bringen.
funktioniert fsck nicht, ist aus obrigen Gründen das Filesystem hinterher stärker beschädigt und oftmals Teile des Inhalts nur noch mit File Carving Methoden wiederherstellbar.

Vorteile von ext4magic

das beschädigte Filesystem wird dabei nicht verändert, da nur Daten daraus gelesen werden
es können mehrere Versuche mit verschiedenen Optionen ausprobiert werden, und notfalls können diese auch abgebrochen werden
Es kommen nur wenige Fehlermeldungen oder Warnungen, die Hauptausgabe ist das Listing der recoverten Dateien, man kann also genau verfolgen ob und was funktioniert.
Eine Überprüfung des bisher erzielten Recover-Ergebnisses ist jederzeit möglich, schon während der Laufzeit.
ext4magic ist tolerant, es muss nicht wirklich versuchen jede noch so absurde Filesystem Information zu interpretieren die sich beim überschreiben der Filesystem-Metadaten ergeben hat, es darf solche unklaren, fehlerhaften und widersprüchlichen Daten ignorieren und überspringen.
Sollten sich in den defekten Bereichen des Filesystems Inode befinden die irgendwelche zufällige aber logisch gültige Werte enthalten, dabei aber auf Datenbereiche von anderen Dateien verweisen, entsteht dabei kein Konflikt der das Recover von scheinbar doppelt benutzten Datenblöcke in den richtigen Dateien verhindern könnte.
Ist das Journal nicht beschädigt, kann ext4magic sich die Informationen von einigen beschädigten Filesystemblöcken aus den alte Kopien im Journal zusammensuchen. Es können somit noch einige Dateien gefunden werden, deren Inode eigentlich schon zerstört ist.
Die Wahrscheinlichkeit eines Absturzes ist sehr sehr gering.
Da das Filesystem nicht verändert wird, bestehen hinterher immer noch alle anderen Optionen es mit anderen Tools oder mit fsck zu versuchen.

ein beschädigtes Filesystem öffnen

Eine der häufigsten Beschädigungen am Filesystem betrifft den Filesystem Anfang. Ein Filesystem welches dort beschädigt ist lässt sich nicht mounten und auch nicht ohne Zusatzoption mit fsck reparieren. Die folgende kleine Exkursion in die innere Struktur eines ext3/4 Filesystems gibt detaillierte Hintergrundinformationen, um mit einer solchen Beschädigung umgehen zu können. Alternativ gibt es ein Script, mit dessen Hilfe auch ohne diese Informationen schnell die richtigen Aufrufoptionen für ext4magic für einen solchen Notfall ermittelt werden können.

die Filesystemblocksize

Die Filesystemblockgröße (block-size) ist die wichtigste Kenngröße des Filesystems. Mit dieser Größe ist im Filesystem festgelegt wie groß ein Block in diesem Filesystem ist, alle internen Adressen des Filesystems arbeiten mit dieser Größeneinheit. Ist sie nicht bekannt, geht gar nichts.
Mögliche Filesystemblockgrößen sind 1024 Byte , 2048 Byte und 4096 Byte. Festgelegt werden sie schon beim Anlegen des Filesystems und sind dann auch nicht änderbar. mit mkfs kann die block-size mit der Option "-b" angegeben werden. Ansonsten wird sie entsprechende der Partitionsgröße automatisch gesetzt. Die meisten Filesysteme werden eine Größe von 4096 haben, kleine Filesysteme habe oftmals 1024, 2048 ist in der Praxis selten zu finden, meist nur dort wo dieses beim Anlegen des Filesystems mit mkfs explizit so angegeben wird.

Solange das Filesystem funktioniert ist die Block-Size schnell zu ermitteln, "ls -l" eines leeren Verzeichnisses wird dieses als Dateigröße anzeigen, aus der Ausgabe des Befehls stat auf irgend eine Datei (dort die Angabe "IO Block") ist es schnell gefunden, oder bei nicht gemounteten Filesystemen kann der Wert aus dem Superblock ermittelt werde. Befehle um den Superblock anzuzeigen sind zB.
tune2fs -l <device>
dumpe2fs <device>
debugfs -R "stats -h" <device>
Ist der Superblock beschädigt, versucht man es bei normalen Filesystemen mit 4096, bei sehr kleinen Filesystemen ist 1024 wahrscheinlich. Funktioniert das Auffinden einer Superblockkopie nicht sofort, muss ein ein wenig probieren. Die Möglichkeiten sind ja überschaubar. Das Script kann auch helfen.

der Superblock

Der Superblock enthält alle wichtigen Eigenschaften des Filesystems, wie Größe, Block-Größe, Inode-Größe, genaue Blockanzahl und vieles mehr. Dieser Block muss beim Mounten gefunden werden auch ohne Kenntnis der Block-size, da diese dort erst heraus gelesen werden muss. Dieser Block beginnt immer 1024 Byte hinter dem Partitions Anfang und nur dort wird er automatisch gesucht. Ohne diesen Block gefunden zu haben, geht nichts.

die Block-Gruppen-Descriptor-Tabelle

Diese befindet sich unmittelbar hinter dem Superblock und kann ein oder auch eine ganze Reihe von Filesystemblöcken beanspruchen. Um zu verstehen was dort drin steht, muss erst ein Begriff geklärt werden "Block-Gruppen".

Intern ist das Filesystem in Gruppen unterteilt. Jede dieser Block Gruppen hat eine bestimmte Zahl von eigenen Inodeblöcken und jeweils einen Block für die Kennzeichnung ob ein Block in dieser Gruppe derzeit belegt oder frei ist (Block Bitmap). Ebenso einen Block für die Kennzeichnung welche Inode in diesem Block derzeit in Benutzung oder frei ist (Inode Bitmap). Eine solche Gruppe umfasst eine feste Anzahl von Filesystemblöcken, die sich errechnen läßt mit "Block-Size * 8"- Damit ist also eine Block Gruppe in einem Filesystem mit einer Block-Size von 4096 Byte
4096 * 8 = 32768 Filesystemblöcke groß und damit genau 32768 * 4096 = 134217728 Byte oder 128 MByte groß.
Die erste Gruppe ist immer Gruppe 0, und die letzte Block Gruppe muss nicht vollständig sein, und umfasst dann den Rest je nach Filesystemgröße.

In der Block-Gruppen-Descriptor-Tabelle stehen von allen Block-Gruppen die genauen Blocknummern in denen sich die Inodeblöcke befinden, welches die Block- und Inode-Bitmap Blöcke sind. Ebenso noch wie viele in jeder Blockgruppe an Blöcken und Inode derzeit frei ist, bei ext4 auch Checksummen usw. Auch ohne diese Block-Gruppen-Descriptor-Tabelle kann mit dem Filesystem nicht gearbeitet werden, da ohne diese Informationen die Dateien nicht gefunden werden können.

Superblock Kopien

Somit stehen unmittelbar am Anfang des Filesystems alle wichtigen Informationen. Ohne diese Informationen kann das Filesystem nicht benutzt werden. Gäbe es davon kein Backup würde eine kleine Beschädigung der ersten Blöcke des Filesystem schon zum Totalverlust des gesamten Filesystems führen. Im Filesystem gibt es also Kopien des Superblockes und der Block-Gruppen-Descriptor-Tabelle. Diese sind an definierten Positionen schon beim Anlegen des Filesystems dort abgelegt worden. Eine entsprechende Ausgabe wo sich diese Kopien befinden, wird beim Anlegen mit "mkfs" zur Information ausgegeben. Auch mit "dumpe2fs" kann man sich die Position dieser Backups anschauen. (vorausgesetzt der Superblock ist noch da ;-) )

 dumpe2fs /dev/sda1 | grep -i Superblock

Woanders wird manchmal empfohlen "mkfs" mit der Option "-n" zur Ermittlung der Superblock Kopien zu verwenden, davor wird hier ausdrücklich gewarnt.

Die Kopien des Superblocks und der Descriptor-Tabelle befinden sich am Anfang der Blockgruppen 1, 3, 5 und 7 weitere sind dann in größeren Abständen noch zu finden je nach Größe das Filesystem, in den Blockgruppen 9, 25, 27, 81, 125, 243, 343, 625, 729 .....
Um mit Hilfe dieser Kopien das Filesystem zu öffnen, muss neben der Block-Size immer die genaue Blocknummer angegeben werden, in welchem sich eine solche Superblockkopie befindet. Diese läßt sich aus der Blockgruppe errechnen.

Blockgruppe * Block-Size * 8

Hier ist eine Anomalie bei der Block-Size 1024 zu beachten, hierbei muss immer zum Schluss noch 1 Filesystem Block addiert werden, da sich der Superblock selbst bei dieser Blockgröße schon im 2. Block des Filesystems befindet.

Beispiele : Reparieren eines ext3 Filesystems mit fsck bei defektem Superblock

fsck.ext3 -B 4096 -b 32768 -y -f /dev/sda1

Bei ext4magic sind die Optionen "-s 4096 -n 32768" anzugeben
zB. um die Dateien aus einem defekten Filesystem zu recovern.

ext4magic /dev/sda1 -s 4096 -n 32768 -c -D

es sind mehr als nur die ersten paar Blöcke defekt

Mehr als nur ein paar wenige Blöcke defekt, dass ist dann zu erwarten, wenn ein Filesystem aus irgend welchen Gründen am Anfang teilweise überschrieben wurde. Was sich unmittelbar hinter der Block-Descriptor-Tabelle befindet ist etwas abhängig vom den Eigenschaften des Filesystems. In älteren Filesystemen kommt hier anschließend sofort die Block- und Inode-Bitmap und die Inodeblöcke der Blockgruppe 0. In neueren Filesystemen welche mit dem Filesystem feature "resize_inode" erstellt wurden. befinden sich dort erst einmal eine ganze Menge reservierter GDT Blöcke. Diese gehören zur Inode 7 und sind für das Auslesen des Filesystems nicht wichtig, damit bilden diese Blöcke dort noch ein mehrere KByte bis wenige MegaByte größes Polster bevor dann wirklich die ersten Metadaten der Blockgruppe 0 überschrieben werden.

In den Metadaten der Blockgruppe 0 befindet sich der Block mit den Inode für das Rootverzeichnis und für das Journal. Auch der erste Daten Block des Rootverzeichnisses ist dort gleich in unmittelbarer Nähe noch zu finden. Hier beginnt also schon Datenverlust. fsck wird bei einer Reparatur ohne die Root-Inode die gesamten Unterverzeichnisse die es finden kann nach "lost+found/" schaufeln. ext4magic hätte noch die Möglichkeit die Daten des Rootverzeichnisses aus dem Journal zu recovern, Die Root-Inode wird mit hoher Wahrscheinlichkeit auch auffindbar sein, aber die Datenblöcke des Rootverzeichnisses wurden das letzte mal bei einer Änderung dort hin geschrieben, und das könnte sehr lange her sein.

Damit ext4magic das Journal aber nutzen kann wenn die Inode des Journals im ersten Inode Block der Blockgruppe 0 zerstört ist, muss es die Inode für das Journal aus dem Superblock oder der angegebenen Superblockkopie recovern werden. Dieses wird bei ext4magic erreicht mit der Expert-Option "-c" .

Werden noch mehr Blöcke ausgehend vom Filesystem Beginn zerstört, erfolgt mehr oder weniger viel Verlust, abhängig vom einigen Filesystem Eigenschaften und dessen Benutzung. Bei ext4 sind in der Blockgruppe 0 Meta-Daten mehrere Blockgruppen, und diese sind oftmals auch gut genutzt. Dafür wird das Journal erst später erwartet, (oftmals komplette Gruppe 4). Bei ext3 hat jede Gruppe ihre eigenen Meta-Daten, die Nutzung der Inode ist auch etwas abweichend zu ext4, so dass hier oftmals nicht ganz so schnell sehr viele Dateien beschädigt sind, aber ältere ext3 Filesysteme könnten gleich in der Gruppe 0 ihre Journaldatem haben, und ohne Journal ist jeder überschriebene Metablock des Filesystems ein verlorener Block.

Es bleibt also immer etwas dem Zufall überlassen was nach einer massiven Zerstörung des Filesystem Anfangs noch für Dateien unbeschädigt sind, und welche Dateien eventuell intern durch die Beschädigungen einen Schaden am Dateiinhalt haben.

Script zum Ermitteln der Optionen für ext4magic

folgendes Script ist gedacht für Filesysteme bei denen der Superblock beschädigt ist, Es versucht mit verschiedenen Blockgrößen Superblockkopien zu finden und gibt die Aufrufparameter auf der Konsole aus, mit denen dieses Filesystem mittels ext4magic über Superblock Kopien zu öffnen und zu recovern ist. (berücksichtigt sind alle Blockdevices und Filesystem Images).

#/bin/bash

# ext4magic  Hilfsscript (dump2fs >= 1.41.9)
# zum ermitteln richtiger Optionen zum ansprechen eines Backupsuperblock
# zum Recovern eines am Beginn teilweise beschaedigten Filesystems mit ext4magic
# Autor robi6@users.sf.net (Version 1.1 vom 03.06.2011)

if [ -b "$1" -o -f "$1" ]
then
   typeset -i BLK BLK_SZ GROUP

   for BLK_SZ in 1024 2048 4096
      do
      for GROUP in 1 3 5 7 9 25 27 49 81 125 243 343 729 2187 2401 3125
         do
         BLK="$BLK_SZ"*8*"$GROUP"
         if [ $BLK_SZ -eq 1024 ]
           then BLK="$BLK"+1
         fi
         dumpe2fs -h -o blocksize="$BLK_SZ" -o superblock="$BLK" "$1" 2>/dev/null | grep UUID &>/dev/null && echo "ext4magic \"$1\" -s $BLK_SZ -n $BLK -c -D"
      done
   done
else
   echo "usage : $0  <device>"
fi
#--------------- END ----------------

Benutzen sie dieses Script wie folgt. (Handelt es sich um ein Blockdevice müssen sie das Script als root ausführen.)

sh script.sh <device>

Als Ausgabe wird eine Liste von ext4magic Aufrufzeilen erwartet. Es kann eine beliebige Befehlszeile davon verwendet werden, um zu versuchen von diesem defekten Filesysteme die Dateien zu recovern. Zusätzlich sollte benutzt werden entweder die Option "-d /Path/zum/Recoverdir" für das Zielverzeichnis, an dem der Recover abgelegt werden soll,
oder es sollte vorher mittels "cd /Path/zum/Recoverdir" in ein ext3/4 Verzeichnis auf einem Filesystem gewechselt werden, welches genügend freien Plattenplatz für das Recover bereitstellt.

Diese Script wird mit neueren Versionen von e2fsprogs funktionieren. Bei sehr alten Versionen muss in der Zeile welche mit "dumpe2fs" beginnt folgendes geändert werden:
-o blocksize="$BLK_SZ" -o superblock="$BLK"
ändern in
-oB"$BLK_SZ" -ob"$BLK"