Ext4magic







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




ext4magic


Basisdaten

Entwickler:

robi

Aktuelle Version:

0.3.2

letzte Veröffentlichung:

12.09.2014

Betriebssystem:

Linux

Kategorie:

System,Filesystem

Lizenz:

GNU General Public License (GPL)

Dokumentation:

Englisch Deutsch

Projekt Seite:

Ext4magic





ext4magic ist ein kleines Tool für die Linux Administration, dass dabei helfen kann, versehentlich gelöschte oder überschrieben Dateien aus einem ext3 oder ext4 Filesystem wieder herzustellen. Gerade auf privaten Rechnern fehlt oft ein ausreichendes und zuverlässiges Backup, oder der Backup Intervall ist aus Kapazitätsmangel viel zu groß gewählt. Nach kleinen oder größeren Konsol- oder Scriptunfällen stellt sich häufig die Frage, kann ich die soeben gelöschten Dateien wieder herstellen?



Die Entwickler des Filesystems sagen einhellig
Bei ext2 war dies möglich, bei ext3 und ext4 sind die Blockverweise auf NULL zurück gesetzt, damit ist ein Wiederherstellen der gelöschten Dateien eigentlich nicht mehr möglich. Es kann versucht werden über Scan- und Suchfunktionen quer über die gesamte Partition den Inhalt der Datei mit viel Glück wiederzufinden.
ext4magic sagt
Wenn das Filesystem mit den normalen Optionen betrieben wurde, dann befinden sich im Journal des Filesystems ungelöschte alte Kopien von jetzt gelöschten Inode- und Filesystemdaten. Mit Hilfe dieser alten Kopien ist es möglich von einem Teil, oft von sogar von sehr vielen, ganz selten auch von allen dieser eben gelöschten Dateien genügend Informationen zu erhalten, um auch jetzt noch eine genaue Kopie der gelöschten Dateien anzufertigen. Es ist von vielen Faktoren abhängig welche brauchbaren Informationen sich in diesem Moment im Journal befinden. Einen Versuch ist es allemal Wert.





Inhaltsverzeichnis

ext4magic Dokumentation

Vorwort des Entwicklers

Seit einiger Zeit gibt es schon 2 Programme, ext3grep und extundelete die es ermöglichen, mit Hilfe von alten Journaldaten solche gelöschten Dateien von ext3/4 zu recovern. Die Leistungsfähigkeit beider Programme ist jedoch stark eingeschränkt. Auch ist der Quellcode aus meiner Sicht wenig geeignet, um weitere Eigenschaften der Dateien und des Filesystems zu integrieren. Der gesamte Quellcode ist sehr unübersichtlich und es ist für fremde Entwickler fast unmöglich an diesem Quellcode weiterzuarbeiten. Dieses war für mich der Auslöser das Problem auf den Erfahrungen der beiden Programme aufbauend, noch einmal von ganz unten neu zu entwickeln. Es wurde von Anfang an versucht möglichst viele Filesystem- und Dateieigenschaften schon zu integrieren und mit noch mehr Heuristik das Optimale aus diesen Journaldaten herauszuholen. Ich hoffe es ist mir gelungen, und die vielen Stunden investierter Freizeit sind gut angelegt.

Derzeitig wird an einem Mehrstufen Recover entwickelt. Es ist gedacht speziell für den Fall eines unbeabsichtigten rekursiven Löschens größer Filesystemstrukturen. Es vereint auf revolutionäre Art das Recover von Inodekopien aus dem Journal mit dem "normalen" Recoververfahren ähnlich dem, wie es in den meisten anderen Tools verwendet wird.


ext4magic hat eine ganze Reihe von Optionen und Funktionen. Auch ohne Hintergrundwissen mit den default Einstellungen wird es möglich sein damit gute Ergebnisse zu erzielen. Eine gute Dokumentation und etwas Hintergrundwissen soll helfen das Maximale in greifbare Nähe zu bekommen. Ich werde die Dokumentation in nächster Zeit hier komplett in Deutsch im Wiki aufbauen und dafür auf eine Web-Projektseite verzichten. Über eine eventuelle Übersetzung sehen wir später weiter.





Hintergrundwissen

In diesem Abschnitt werden einige Ausgabeformate von ext4magic Funktionen beschrieben. Ein wenig Hintergrundwissen wird vermittelt, welches man benötigen würde, um auch spezielle ältere Dateiversionen zu finden und zu recovern, oder auch einzelne Dateien wiederherzustellen, die von den automatischen rekursiven Recoverläufen von ext4magic eventuell nicht gefunden werden können.
Ebenfalls sind in diesem Abschnitt wichtige Informationen und Erfahrungen, wie ext4magic benutzt werden kann und wie einige Optionen und Parameter am günstigsten und sinnvollsten zu setzen oder einzustellen sind.





Inode

Dreh und Angelpunkt jedes Dateizugriffs ist die Inode.

In der Inode einer Datei sind sämtliche Eigenschaften der Datei hinterlegt, mit Ausnahme der Inodenummer und des Dateinamens. Die Inodenummer ist eine Indexnummer unter der sich die jeweilige Inodedatenstruktur innerhalb einer Inodetabelle befindet. Der oder die (mehrere) Dateinamen befinden sich in den Verzeichnis-Daten, immer zusammen mit einer dazugehörigen eindeutigen Inodenummer.

Die typische Inode Größe war ursprünglich 128 Bit, dort sind alle oder die allermeisten Informationen untergebracht. Heute werden meist 256 Bit Inodegröße angelegt. Bei einer Filesystemgröße von 4 KByte sind somit bei 256 Byte Inodegröße immer 16 Inode in einem Filesystemblock enthalten. Das Filesystem muss bei Veränderungen immer einen ganzen Filesystemblock neu schreiben, und damit auch diesen ganzen Inodeblock ins Journal als Kopie sichern, auch wenn sich nur eine einzelne Inode verändert hat. Somit sind im Journal dann auch Kopien von Inode zu finden, obwohl diese Inode gar nicht verändert wurden.

Der Inhalt der Datei befindet sich in Datenblöcken die von der Inode adressiert werden. Die meisten Eigenschaften einer Datei, so wie sie in der Inode hinterlegt sind, sind fast selbst erklärend und wir brauchen nicht näher darauf eingehen. (Beispiele von Inodeausgaben die von ext4magic erzeugt werden, in der Gegenüberstellung der Ausgabe die stat in Linux anzeigt.)

Einer der Hauptunterschiede zwischen ext3 und ext4 liegt in der Adressierung der Datenblöcke in der Inode. Kenntnisse über die Funktion von Adressierung von ext2/3 oder der ext4 Extents benötigt man bei der Nutzung von ext4magic nicht. Es genügt zu wissen, in beiden Fällen wird beim Löschen der Datei unter anderem die Adressierung der Datenblöcke in der Inode zerstört, in dem sie komplett auf NULL gesetzt werden. In diesem Zustand läßt sich aus dieser Inode keine Datei recovern. Wir benötigen von einer gelöschten Datei immer eine Kopie der Inode im ungelöschtem Zustand.

Ist eine Inode gelöscht, steht sie für eine neue Verwendung für eine neue Datei frei zur Verfügung. Die Wahrscheinlichkeit, das eine Inode sofort oder schnell wieder genutzt wird, ist unterschiedlich groß. Das Filesystem ist bestrebt die Inode in den Verzeichnissen zu gruppieren. Man kann das auch erkennen, wenn man sich mit "ls -il" ein paar Verzeichnisse anschaut. Dort wird man sehr oft Gruppen von aufeinander folgenden Inodenummern finden. Wiederverwendete Inode sind für ext4magic nicht das wirkliche Problem, da sowieso nur die alten Kopien aus dem Journal benötigt werden. Allerdings werden vorzugsweise immer Datenblöcke aus dem gleichem Filesystemabschnitt für neue Dateien verwendet. Damit steigt bei Wiederverwendung von gelöschten Inodes auch die Wahrscheinlichkeit, das auch die beim löschen frei gewordene Datenblöcke schnell wieder überschrieben werden. Dieses wird dann doch zum Problem wenn man gelöschte Daten wieder herstellen will.



Daraus kann man einige Wahrscheinlichkeiten ableiten:

* wird zB. eine einzelne Datei in einem Verzeichnis gelöscht und anschließend eine neue Datei im selben Verzeichnis neu erstellt, dann ist die Wahrscheinlichkeit groß, das diese eben gelöschte Inode sofort wieder verwendet wird. Die frei gewordenen Datenblöcke finden oft nicht sofort aber meist schnell wieder Verwendung wenn weitere Dateien angelegt werden.
* wird eine Datei ohne Löschung direkt überschrieben, wird die Inode weiterverwendet, die Eigenschaften der Datei bleiben auch erhalten. Es werden dabei jedoch andere Datenblöcke für die Daten verwendet, die überschriebene Datei könnte jetzt problemlos wiederhergestellt werden.
* werden ganz Verzeichnisse oder Verzeichnisbäume gelöscht, und anschließend in einem anderem Verzeichnis einige neue Dateien angelegt, ist es weniger wahrscheinlich, dass die eben gelöschten Inode sofort wieder verwendet werden. Die Datenblöcke die im anderen Verzeichnis frei geworden sind sind, werden hierbei auch mit geringer Wahrscheinlichkeit für solche Dateien in anderen Verzeichnissen verwendet.
* Werden in einem Verzeichnis mehrere Dateien gelöscht und anschließend im selben Verzeichnis neue Dateien angelegt, ist die Wahrscheinlichkeit groß, dass dadurch auch die alten Datenblöcke schnell wieder überschrieben werden.
* In Verzeichnissen in denen viel mit Editoren gearbeitet wird, (welche beim editieren die Originaldatei in ein Backup umbenennen und dadurch ein altes Backup dieser Datei überschreiben und das Ergebnis beim Abspeichern in eine neue Datei abspeichern, somit also bei editieren die Dateien, Inode und Datenblöcke ständig rotieren), kann nach wenigen Änderungen an den Dateien und trotz vollständigen Inodekopien im Journal oftmals nur die letzte Version der letzten geänderten Datei wieder hergestellt werden, da die beim Überschreiben der alten Backupdateien frei werdenden Datenblöcke regelmäßig schnell wieder verwendet werden. Werden dort ständig mehrere Dateien auf diese Art rotiert, sind oftmals kaum ältere Versionen der Dateien wiederherstellbar.



Die genaue Bedeutung der 3 bis 5 Zeitstempel der Inode die von ext4magic angezeigt werden. sollte man kennen. Das Tool benötigt 2 Zeitangaben für seine Suche in den Journaldaten. Die default Einstellung für diese Zeitangaben sind sehr breit und ungenau (letzten 24 Stunden). Um spezielle ältere Filesystem- oder Dateiversionen zu finden muss man dem Programm beim Aufruf genauere Zeitangaben mitgeben. Eine Quelle zum herausfinden von benötigten Zeitenangaben, ist die Ausgabe der Inodedaten. In den Ausgabebeispielen wird die Bedeutung der Zeitstempel hinreichend erklärt.





Verzeichnis

Verzeichnisse sind eine spezielle Dateiform. In den Daten dieser Dateien stehen die Dateinamen und die dazugehörige Inodenummern eines Verzeichnisses. Die Verkettung der Verzeichnisdateien untereinander ergibt letztlich den Path, innerhalb der eine Datei im Dateibaum des Filesystems gefunden wird.

Die Daten in den Verzeichnisblöcken bestehen aus einer Art Tabelle, in denen außer dem Dateinamen, der dazu gehörigen Inodenummer und einem Flag, welches den Dateitype grob bestimmt, nicht viel mehr enthalten ist. Die einzelnen Einträge sind wie eine Kette untereinander verbunden. Jeder Eintrag enthält einen Hinweis wo der nächste Eintrag beginnt. Werden jetzt Dateien gelöscht, dann wird erst einmal nur diese Verknüpfung verändert und der Eintrag für die gelöschte Datei wird dabei ausgekettet und somit beim Auswerten in der Liste übersprungen. Der ehemalige Dateiname und die dazugehörige Inodenummer bleibt aber erst einmal dort erhalten. Der Eintrag wird nur beim Auslesen der Daten jetzt übersprungen. Eine Bereinigung alten Einträge erfolgt bei Bedarf nach und nach automatisch, wenn die Daten dieses Verzeichnisses wieder neu geschrieben werden. Ur-Alte Einträge bleiben jedenfalls nicht auf ewige Zeit dort enthalten.

Somit ist es für ext4magic möglich auch einen Dateinamen seiner ehemaligen Inodenummer noch zu zuweisen, auch wenn die Datei gelöscht ist. Allerdings gibt es hier einige Probleme. Im Normalfall kann es pro Verzeichnis nicht vorkommen, dass ein Dateiname dort doppelt vergeben ist. Werden die gelöschten Einträge jedoch mit untersucht, dann kann und wird genau das aber vorkommen. Wird eine Datei gleichen Namens mehrfach angelegt und wieder gelöscht, dann hat der Dateiname zeitlich zu jedem Zeitpunkt nur maximal ein Mal im Verzeichnis existiert. In den Verzeichnisböcken werden aber eventuell mehrere dieser Namen gefunden, die dann auf die gleiche oder auf eine ganz andere Inodenummer verweisen, oder Einträge mit diesem Namen die schon teilweise bereinigt wurde und eine Inodenummer "0" enthalten. Bis auf einen Namen müssen alle anderen ausgekettet und somit gelöscht sein.

Auch ist es möglich, das man dort Dateinamen von gelöschten Dateien findet, deren ursprüngliche Inode in der Zwischenzeit schon von einer anderen Datei benutzt wird. Wann eine Datei existiert hat und wann sie gelöscht wurde, kann nur aus der Inode selbst ermittelt werden, auf die der Verzeichniseintrag verweist. Die Zeitoptionen die beim Aufruf an ext4magic mitgegeben werden können, übernehmen anhand der Inodezeiten die Auswahl, welcher Eintrag jetzt herangezogen wird und welcher nicht. Dabei werden zwangsläufig Fehler vorkommen, zB wenn die Daten im Journal unvollständig oder gar nicht mehr vorhanden sind, wenn die Zeitoptionen ungünstig gewählt werden, und auch wenn eine wiederverwendete Inode in der Zwischenzeit auch schon wieder gelöscht ist.


Die Datenblöcke der Verzeichnisse werden wie die Inodeblöcke bei Veränderungen in das Journal kopiert. Dort sind sie aber seltener anzutreffen, als die Inodeblöcke. Die Inodedaten ändern sich viel häufiger und oftmals auch, ohne das sich die Datenblöcke der Verzeichnisse ändern. ext4magic versucht immer die passenden Verzeichnisdatenblöcke zu einer Inodekopie einer Verzeichnisdatei im Journal zu finden. Sind diese jedoch nicht vorhanden, nimmt das Programm die nächst folgende Kopie dieses Blockes die es im Journal finden kann. Wird auch so eine Kopie nicht gefunden, dann wird letztlich der Block aus dem Filesystem entnommen. Ext4magic kann also nicht mit absoluter Genauigkeit bestimmen, das der Verzeichnisblock auch wirklich zeitlich genau zur Inodekopie der Verzeichnisdatei gehört. Ext4magic ist so programmiert, das es hier mit dem nächst kleinerem Übel ohne murren weiter arbeitet.

Damit unter diesen Voraussetzungen noch ausreichend vollständige und gute Ergebnisse zu erhalten sind, wird ext4magic dafür aber komplett darauf verzichten, die Auskettung gelöschter Dateinamen in den Tabellen der Verzeichnisblöcken auszuwerten. Nur dort kann es Differenzen geben, wenn eine spätere Kopie eines Verzeichnisblockes benutzt wird. Es nimmt seine Auswertung nur an Hand der Daten in der Inodes vor und behandelt alle einigermaßen plausiblen Einträge in den Verzeichnis Tabellen gleich, egal ob sie gelöscht oder nicht gelöscht markiert sind.


Derzeit gibt es nur eine Zusatzoption für die Recoveroptionen. -Q bezeichnet als "optional high quality Option", die sich wirklich auf Löschmarkierungen in Verzeichnisdaten verlässt. Beim Benutzen dieser Option werden von den Einträgen nur ungelöschte berücksichtigt. Diese Option kann nur wirklich richtig und zuverlässig funktionieren, wenn vom entsprechendem Filesystem Abschnitt die Kopien der entsprechenden Verzeichnisdatenblöcke vorhanden sind, und die Zeitoptionen optimal gesetzt werden. In diesem Fall ist das Ergebnis allerdings sehr gut, und es werden so gut wie keine Fehler durch doppelt benutzt Dateinamen oder wiederverwendete Inode entstehen. Nähere Informationen zu dieser Option im Abschnitt Tricks und Tipps

Beispiele für Verzeichnisausgaben von ext4magic mit den entsprechenden Erläuterungen.





Journal

Das Journal ist der Dreh und Angelpunkt von ext4magic.
Um die Hauptseite nicht zu überfüllen, wurde dieser Bereich auf eine eigene Journalseite ausgelagert.





Installation von ext4magic

Eine Installation sollte derzeit nur auf Linux Systemen möglich sein, andere Betriebssysteme sind nicht berücksichtigt.

Einige Distriburtionen stellen Community Pakete zur Verfügung

Die Entwicklung von ext4magic erzeugt einige full feature Pakete mit Hilfe von openSUSE Build Service

Sollte kein fertiges Paket für die erforderliche Distribution zu finden sein, ext4magic kann aus dem Quellcode erstellt werden.
Folge den Instruktionen auf der Installations Seite.


Versionshinweis: derzeit verfügbar ist:







Benutzung von ext4magic

Beim Aufruf von ext4magic muss immer das Filesystem als Argument mit übergeben werden. Als Filesystem kann sowohl ein Blockdevice als auch ein Images einer Partition genutzt werden.
Der sicherste Weg bei allen größeren Filesystem Problemen und ebenfalls bei der Arbeit mit ext4magic ist immer nur mit einer Kopie der Partition oder der Platte zu arbeiten und die Originaldaten nicht zu verändern. Sollte der ersten Versuch ein Filesystem zu reparieren oder die Daten darauf zu retten nicht funktionieren, kann erneut eine Kopie von den Originaldaten vom Filesystem hergestellt werden und mit dieser ein anderes Programm oder anderes Howto ausprobiert werden. So hat man theoretisch unendlich viele Versuche verlorene Daten doch noch wiederherzustellen. Dieser Weg ist auch mit ext4magic anzuraten, obwohl ext4magic keine Änderungen am Filesystem vornehmen wird.





Das richtige Erstellen eines Filesystem Images

Bei der Erstellung einer Kopie des Filesystems entweder als Image, in eine andere Partition oder auf eine andere Platte sollte folgendes jedoch unbedingt beachtet werden.
Das Filesystem sollte während des Kopierens nicht in Benutzung oder maximal read-only gemountet sein. Beim Erstellen einer Kopie zB mit dd, werden die Filesystemdaten seriell von Anfang bis Ende kopiert. Dieses dauert entsprechend der Größe eine gewisse Zeit. Würde zur gleichen Zeit aber jetzt noch in das Filesystem geschrieben, dann entstehen mehr oder weniger große Inkonsistenzen in der Filesystemstruktur. Besonders anfällig dafür ist das Filesystemjournal. Mit großer Sicherheit ergeben sich so fehlerhafte Daten im Journal, da der Journalinhalt zeitlich nicht mit dem Filesystemzustand identisch ist. Dieses wird noch verstärkt durch die Ringbuffer Verwendung des Journals. Bei einem mount wird sich fsck nur für ein vermeintliches Ende in der Journalkopie interessieren, ext4magic sucht und nutzt jedoch auch alle anderen alten Daten im Journal. ext4magic würde bei solchen Fehlern im Journal einige Blockkopien im Journal als Kopien von völlig anderen Filesystemblöcken interpretieren. Die Fehler und Fehlinterpretationen die daraus entstehen werden vom Programm selbst nur bemerkt, wenn sich bei der Verarbeitung völlig absurde Daten ergeben, ansonsten wird ext4magic mit diesen falschen Daten weiterarbeiten. Möglich sind dann völlig falsche Ergebnisse, Fehlermeldungen oder auch Programmabbruch wegen fehlerhafter Speicherzugriffe.

Anmerkung:

Kopien des Filesystems die für die Verwendung mit ext4magic vorgesehen sind, sollten vor der Benutzung mit ext4magic nicht, oder maximal "read-only" gemountet werden und kein Filesystemcheck darauf ausgeführt werden. Notfalls das Filesystem mit der Option "-noload" mounten oder vorher eine Kopie des Journals erstellen (Tricks & Tipps). Werden solche Kopien zum schreiben gemountet, werden sonst schon bei einfachen List und Leseoperationen Journaldaten überschrieben und so unnötig Chancen auf Wiederherstellung verschenkt







Wie können Filesysteme genutzt werden

Es können sowohl umountete als auch readonly gemountete Filesysteme, oder Image von Filesystem Partitionen direkt benutzt werden. Es soll in diesem Beispielen jeweils nur der Filesystem Superblock angezeigt werden. 

ext4magic /PATH/ZUM/IMGAGE/filesystem.image -S
ext4magic /dev/sdb3 -S

Wurde ein Image der kompletten Platte erstellt, kann dieses mit Hilfe von Loopdevices ebenfalls genutzt werden. Dazu muss mit einem Offsetwert gearbeitet werden. Unter Tricks & Tipps ist eine kleines Hilfsscript zu finden, welches hier helfen könnte.
Das Loopdevice kann dann genau so benutzt werden wie eine Filesystempartition 

ext4magic /dev/loop0 -S

Software RAID , Logische Volume und verschlüsselte Dateisysteme müssen gestartet werden und können dann über den Geräteknoten der auch beim mounten verwendet wird mit ext4magic angesprochen werden. Gemountet sollte die Filesysteme möglichst dabei nicht sein, maximal read-only. Ein ausführliches Beispiel für die Bearbeitung eines mit LUKs verschlüsselten Container ist auf der Tricks und Tipps Seite zu finden.


Im Moment in dem Dateien versehentlich gelöscht oder überschrieben werden, ist das Filesystem "read-write" gemountet. Sobald der versehentliche Fehler bemerkt wird, möglichst alle weiteren Schreib- und Leseaktionen in diesem Filesystem unterlassen. Sollte es möglich sein, das Filesystem jetzt auszuhängen, dann ist das ein guter Zeitpunkt dieses jetzt auch zu tun, ext4magic kann so im ungemounteten Zustand benutzt werden, oder zuerst eine Kopie des Filesystems herstellt werden. Wird der Rechner jetzt herunterfahren oder rebootet, dann ist zu verhindern, dass beim nächsten Start dieses Filesystem automatisch wieder "read-write" eingebunden wird. Zum Beispiel durch Start im Single User Mode, oder durch auskommentieren in der /etc/fstab. Ebenfalls zu verhindern ist ein automatischer Filesystemcheck, dieser könnte beim Aufräumen für das Wiederherstellen von gelöschten Dateien wertvolle Informationen aus dem Filesystem entfernen

Kann aus irgend einem Grund das Filesystem nicht ausgehängt werden, kann versucht werden, das Filesystem ohne Unterbrechung nach "read-only" zu remounten. 

mount -o ro,noload FILESYSTEM

Ist auch dieses nicht möglich weil Dateien zum Schreiben offen sind, und der Rechner muss zwingend, oder soll jetzt noch mit dem "read-write" eingehängten Filesystem weiter arbeiten, dann auf keinen Fall das Journal eines "read-write" gemountetes Filesystem jetzt direkt mit ext4magic nutzen, auch wenn scheinbar nicht viel auf das Filesystem geschrieben wird. Ausführung dazu und eine mögliche Umgehung des Problems sind auf der Tricks & Tipps Seite hinterlegt.





die richtige Interpretation des Histogramm

Das Histogramm ist eine Hilfsfunktion von ext4magic. Sie soll helfen für die Zeitoptionen die richtigen Werte anhand von auffälligen Veränderungen im Filesystem zu finden. Zeitmarken werden von vielen Optionen von ext4magic erwartet, ansonsten werden voreingestellte Werte benutzt, welche sehr grob sind und nicht in jedem Fall zum Erfolg führen können. Das Histogramm ist hier eine gute Möglichkeit um sich im zeitlichen Verlauf der Geschehnisse zu orientieren und durch Einschachteln ist es möglich die genauen Werte zu ermitteln.
Die Ausgaben dieser Optionen sehen einfach aus, sind allerdings ohne ein wenig Dokumentation nicht ganz einfach zu interpretieren.

Die prinzipielle Funktionsweise
Es werden Zeitstempel der Inode des Filesystems gezählt. Dabei wird im untersuchtem Zeitbereich eine Unterteilung in 10 ( bzw 20 Abschnitte bei zusätzlicher Option "-x" ) vorgenommen. ext4magic versucht anhand der Ergebnisse einen Maßstab zu finden und zeigt die gezählten Inode pro Zeitbereich als einfaches Balkendiagramm. Untersucht werden die ctime und die dtime der Inode. Sollten auch Inode mit gesetzter crtime in diesem Zeitraum auftreten, dann wird daraus ein zusätzliches Histogramm erzeugt.


dabei gelten folgende Regeln

  1. es wird jeweils nur der letzte Zeitstempel einer Inode gewertet, mehrmalige Änderungen bleiben unberücksichtigt, liegt die letzte Änderung zeitlich außerhalb des Untersuchungszeitraums, wird diese Inode im Historgamm nicht gewertet.
  2. die gewerteten Änderungen im Untersuchungszeitraum werden pro Inode entweder im Bereich dtime gewertet, wenn die Datei zuletzt gelöscht wurde, oder im Bereich ctime, wenn zuletzt im Zeitraum eine andere Änderung als das Löschen erfolgt ist.
  3. die Auswertung der crtime ist zusätzlich und unabhängig von der ctime und dtime Wertung. Von einer zum entsprechenden Zeitpunkt bereits gelöschten Datei, wird jedoch keine crtime gewertet.



Beipiele für Histogrammausgaben





Die Zeit-Optionen für ext4magic

Das Programm arbeitet intern in einer Vielzahl von Funktionen mit 2 Zeitmarken.

"AFTER"-Zeit
diese Zeit wird mit der Option "-a <n>" festgelegt. Alles was vor dieser Zeit gelöscht wurde, wird nicht berücksichtigt.
"BEFORE"-Zeit
diese Zeit wird mit der Option "-b <n>" festgelegt. Alle Änderungen nach dieser Zeit werden nicht mehr berücksichtigt






Diese beiden Zeitmarken entscheiden welche Inodekopie aus dem Journal bei der internen Bearbeitung benutzt werden soll, und welche nicht. Somit sind diese Zeitmarken wichtige Steueroptionen für den Programmablauf und beeinflussen wesentlich das Ergebnis. Sie sind individuell entsprechend der jeweiligen Gegebenheiten auf dem Filesystems anzugeben. Die default Einstellung sind nur eine sehr grobe Einstellung welche in einfachen Situationen aber schon ausreichen kann. In vielen Fällen müssen hier jedoch Zeiten vorgegeben werden. (zB. der Löschzeitpunkt ist älter als 24 Stunden, oder eine Datei wurde überschrieben, Verzeichnisse wurden verschoben oder umbenannt)
Genaue Zeitangaben sind dann notwendig, wenn sich die Datei oder Verzeichnisstruktur wesentlich geändert hat, um möglichst fehlerfrei die Dateien und Verzeichnisse zu finden, die zum Zeitpunkt zwischen "AFTER" und "BEFORE" existent waren.

In Versionen > 0.1.4 gibt es spezielle Optionen für ein mehrstufiges Recover. ( "-m" und "-M" ) Bei diesen Optionen wird eine wesentlich anwendungsfreundliche default Einstellung für die Zeit verwendet. ext4magic versucht hierbei, soweit keine "AFTER" Zeit angegeben wurde, selbständig die optimale Zeit vor dem letztem Löschvorgang zu finden und nutzt diese automatisch ermittelte Zeitmarke für den Recover, auch wenn der Löschvorgang schon länger als 24 Stunden zurück liegt. Diese automatische Suche nach dem Löschzeitpunkt sind jedoch nur optimal für ein versehentliches recursives Löschen gewählt. Genau genommen wird der letzte Löschvorgang gesucht und alle Löschungen die bis 5 Minuten vorher gelaufen sind mit eingeschlossen. Wurde nach einem solchem Löschvorgang dann später jedoch noch eine Datei gelöscht, dann kann dieser Automatismus nicht funktionieren. Ebenfalls nicht funktionieren kann dieses automatische Suchen des Löschzeitpunktes, wenn die Dateien zB. mittels eines Move-Kommandos gelöscht worden sind, da dieses eventuell länger als 5 Minuten gedauert hat. In solchen Fällen muss die "AFTER-Time" angegeben werden, und zwar unmittelbar vor der ersten Löschaktion. Hierzu am Besten den Beginn Löschzeit mittels des Histogramm ermitteln.

Hilfestellung um die Zeitmarken optimal einzusetzen.





List- und Recover-Optionen

ext4magic arbeitet bei den meisten Optionen zum Recovern der Dateien und zum Auflisten der Dateinamen im Verzeichnisbaum intern recursiv und arbeitet sich so unter Zuhilfenahme der Journaldaten durch das Filesystem. Anzugeben ist hierbei das Startverzeichnis als Name oder als Inodenummer. Default (ohne spezifische Eingabe) ist das Wurzelverzeichnis dieses Filesystems der Startpunkt.


Geschrieben werden die recoverten Dateien in ein seperates Verzeichnis. Dieser Zielordner ist per Voreinstellung "RECOVERDIR/" im aktuellem Verzeichnis bei Aufruf des ext4magic Kommandos. Es kann aber auch durch die Option "-d <target_dir>" beim Aufruf selbst ein Zielordner für das Recover bestimmt werden. Dieses Verzeichnis sollte sich auf einem ext3/ext4 Filesystem befinden und genügend freie Speicherkapazität haben, um die Dateien wiederherzustellen.

Bei Angabe des Startverzeichnisses als Dateiname, werden die Dateien im Zielverzeichnis mit vollem Path wieder angelegt. Wird das Verzeichnis über die Inodenummer adressiert, wird der Name und Path dieser Start-Inode nicht aufgelöst, und das Verzeichnis "<INODENUMMER>" die darin wiederhergestellten Daten enthalten. Darunterliegende Datei- und Verzeichnisnamen werden voll aufgelöst. 

ROBI@LINUX:/ # ext4magic /dev/hda3 -f rob/Bilder -r
"RECOVERDIR"  accept for recoverdir
Filesystem in use: /dev/hda3

Using internal Journal at Inode 8
Inode found "rob/Bilder"   737371
Inode 737371 is allocated
--------        RECOVERDIR/rob/Bilder/pict0074.jpg
--------        RECOVERDIR/rob/Bilder/pict0083.jpg

die selben Dateien wiederhergestellt mit Adressierung über die Verzeichnis Inode 

ROBI@LINUX:/ # ext4magic /dev/hda3 -I 737371  -r
"RECOVERDIR"  accept for recoverdir
Filesystem in use: /dev/hda3

Using internal Journal at Inode 8
Inode 737371 is allocated
--------        RECOVERDIR/<737371>/pict0074.jpg
--------        RECOVERDIR/<737371>/pict0083.jpg





die List-Option "-L" für alle Dateinamen
Es werden alle Dateinamen mit ihren Inodenummern ab dem Startverzeichnis aufgelistet, welche das Programm mit den gegebenen Zeitoptionen findet. Dabei wird keinerlei Unterscheidung zwischen gelöschten und ungelöschten Dateien getroffen. Die Ausgabe enthält pro Zeile eine Marke "DIR" für ein Verzeichnis oder "---" für alle anderen Dateien, sowie die Inodenummer und den kompletten Dateinamen. 
ROBI@LINUX:/ # ext4magic /dev/sda3 -f rob/Bilder -L
Filesystem in use: /dev/hda3

Using internal Journal at Inode 8
Inode found "rob/Bilder"   737371
Inode 737371 is allocated
DIR     737371   rob/Bilder
---     754190   rob/Bilder/scan05.jpg
---     754333   rob/Bilder/scan07.jpg
---     754411   rob/Bilder/scan09.jpg
---     754437   rob/Bilder/scan01.jpg
DIR     738576   rob/Bilder/Male_2009
---     738577   rob/Bilder/Male_2009/imga0211.jpg
---     738578   rob/Bilder/Male_2009/imga0212.jpg





die List-Option "-l" für Dateien die wiederherstellbar sind.
Es wird hierbei jede Inode darauf hin geprüft, ob die adressierten Datenblöcke dieser Inode unbenutzte Datenblöcke hat. Es wird die Prozentzahl der unbenutzen Datenblöcke dieser Datei angezeigt gefolgt vom kompletten Dateinamen. Dateien die hier mit "100%" gekennzeichnet sind, sind entweder gelöschte Dateien die sich von ext4magic wiederherstellen lassen, oder Dateien die selbst keine Datenblöcke benutzen, wie zB leere Dateien oder Symlinks und andere Sonderdateien. Dateinamen die hier angezeigt werden, mit einem Prozentsatz kleiner "100%", sind gelöschte Dateien bei denen ein Teil der verwendeten Datenblöcke in der Zwischenzeit schon überschrieben ist. Diese Dateien währen mit sehr großer Wahrscheinlichkeit beschädigt, wenn man sie recovern würde. Eventuell würden sich bei verschiedenen Dateitypen noch Teile einer solchen recoverten teilweise defekten Datei nutzen lassen.

Dateinamen die nur aktuell benutzte Datenblöcke haben, werden nicht mit angezeigt, Somit werden hier nicht angezeigt, gelöschte Dateien, die sich nicht mehr herstellen lassen, weil alle Datenblöcke überschrieben sind, ebenfalls nicht angezeigt werden alle ungelöschte Dateien die Datenblöcke besitzen. 

ROBI@LINUX:/home/rob/test # ext4magic testfile.iso -f "user1"  -b 1275076685 -l
Filesystem in use: testfile.iso
Using internal Journal at Inode 8
Activ Time after : Thu May 27 23:02:29 2010
Activ Time before: Fri May 28 21:58:05 2010
Inode found "user1"   60929
Inode 60929 is allocated
   92%   user1/cimg1433.jpg
   88%   user1/cimg1434.jpg
   94%   user1/cimg1435.jpg
  100%   user1/cimg1436.jpg
  100%   user1/cimg1437.jpg
  100%   user1/cimg1438.jpg
  100%   user1/cimg1439.jpg
  100%   user1/cimg1441.jpg





die Recover-Option "-R" für das Wiederherstellen aller Dateien
Diese Option ist das Equivalent zur Option "-L". Es wird versucht von jeder Inode-Dateinamen-Kombination, welche mit "-L" angezeigt wird, eine Kopie herzustellen. Dabei wird keine Unterschied gemacht ob eine Datei gelöscht ist, oder nicht, und wie der Zustand der Datenblöcke ist. Es wird versucht von jeder gülltigen mit den Zeitoptionen gefunden Inode eine Datei zu recovern. Diese Option hat noch die Besonderheit, es wird versucht nicht nur die original Eigenschaften der Daten-Dateien wiederherzustellen, sondern auch die Eigenschaften aller Verzeichnisse. Diese Option ist insbesondere dann anzuraten, wenn zB der gesamte Verzeichnisbaum gelöscht wurde, oder wenn ein jetzt teilweise gelöschter Verzeichnisbaum möglichst wieder so hergestellt werden soll, wie er innerhalb des Zeitfensters existent war. Mögliche Konflikte mit überschriebenen oder wiederverwendeten Datenblöcken werden bei dieser Option nicht bemerkt. Je länger der Löschzeitpunkt einer Dateien zurückliegt und man noch schreibend auf das Filesystem zugegriffen hat, um so größer wird dadurch die mögliche Fehlerquote auch falsche und defekte Dateien zu recovern, und es müssen alle Dateiinhalte daraufhin überprüft werden.





die Recover-Option "-r" für das Wiederherstellen aller gelöschten Dateien
Mit dieser Option werden jetzt nur alle Dateien wieder hergestellt, die keine Konflikte mit zur Zeit im Filesystem verwendeten Datenblöcken haben. Das sind einerseits alle Dateien welche keine Datenblöcke benutzen, zB. leere Dateien, und alle gelöschten Dateien deren Datenblöcke noch nicht überschrieben sind. Defekte oder falsche Dateien könnten hier nur entstehen, wenn die Datenblöcke einer Datei in der Zwischenzeit schon wiederverwendet wurden und diese Dateien in der Zwischenzeit auch schon wieder gelöscht sind. Es werden bei dieser Option keine original Eigenschaften der Verzeichnisse wieder hergestellt. Diese Option ist dann nutzbar wenn nur einzelne Dateien gelöscht wurden oder man nur die gelöschten Dateien wieder herstellen will. Ebenfalls anwendbar, wenn der Löschvorgang schon länger zurückliegt und man wirklich nur noch die Dateien wieder herstellen möchte, die wahrscheinlich noch unbeschädigt sind. Bei dieser Option werden eventuell einige Dateien recovert obwohl die Dateien gar nicht gelöscht sind. Es handelt sich um Dateien, die keine Datenblöcke nutzen, zB. leere Dateien, Symlinks, Gerätedateien usw. Anhand der Größe und des Typs sind sie anschließend jedoch schnell erkannt, so das man sie von den wichtigen Daten doch schnell unterscheiden kann.


Ebenso können einzelne Dateien mit den Optionen "-R" und "-r" sowie eine Dateinamenslisten mit diesen beiden Optionen wieder hergestellt werden. Das Verhalten in Bezug auf unbenutzte Datenblöcken ist analog dem oben beschriebenen. Die Verzeichnis Eigenschaften werden hier nicht gesetzt. Eine einzelne Datei zu recovern kann dazu benutzt werden, um eine bestimmte Inodekopie mit Hilfe der Transaktionsnummer auszuwählen. Dieses kann zB genutzt werden wenn sich eine Datei innerhalb kurzer Zeit mehrfach geändert hat und man eine bestimmte Version der Datei recovern möchte. Bei ext3 kann es gelegentlich vorkommen, dass im Journal der Löschprozess einer sehr großen Datei in 2 Stufen vermerkt ist. ext4magic wird in den automatischen Recoverläufen die erste ungelöschte Inodekopie vor der BEFORE-Zeit benutzen, bei Dateien die in mehreren Etappen gelöscht worden sind, ist das nicht die gesamte ursprüngliche Datei. Auch hier kann man die gesamte Datei gezielt über die Transaktionummer wieder herstellen.



Recover-All(ab Version 0.2.1)
Werden die Optionen "-R" oder "-r" auf das gesamte Filesystem und nicht nur auf ein bestimmtes Unterverzeichnisse angewendet, wird die erste Stufe der Magic-Optionen nachgestartet. Diese findet dann noch alle zum Zeitfenster passenden gelöschten Dateien die wegen fehlender Journaldaten von Verzeichnissen nicht beim durchsuchen des Dateibaumes gefunden werden konnten. Diese Dateien und Verzeichnisse werden unter MAGIC-1 (gefunden Unterverzeichnisse) und MAGIC-2 (einzelne gefundene Dateien) abgelegt und tragen die Inodenummer im Dateiname.





Dateinamensliste
mit der Option "-i <input_file>" kann eine Dateinamensliste in Form einer Datei zum recovern den Optionen "-r" oder "-R" übergeben werden. Die Dateinamen müssen dabei Zeilenweise und in doppelte Anführungszeichen " eingeschlossen sein. Alle nicht sauber eingeschlossenen Dateinamen, und alle Bereiche der Zeile vor und hinter den Anführungszeichen werden ignoriert. Solche Listen lassen sich sowohl mit der Option "-L" wie auch mit "-l" erstellen, indem dort die Zusatzoption "-x" verwendet wird und können per Hand oder per Script bearbeitet werden. Diese Listen sollten immer mit den selben Zeitoptionen gestartet werden, mit denen sie auch hergestellt wurden.




Die Ausgabe beim Wiederherstellen von Dateien ist in allen Fällen gleich.
Beispielausgabe von einem Recover: 

--------        RECOVERDIR/user1/cimg1436.jpg
--------        RECOVERDIR/user1/cimg1437.jpg
--------        RECOVERDIR/user1/cimg1438.jpg
--------        RECOVERDIR/user1/cimg1439.jpg
--------        RECOVERDIR/user1/cimg1441.jpg

Die führende Ausgabe von "--------" bedeutet hier, die Dateieigenschaften konnte ordnungsgemäß wieder hergestellt werden. Sollten sich beim Wiederherstellen der Dateien und ihrer Eigenschaften Probleme ergeben haben, so sind diese in diese hier in diesem String als "x" markiert. Solche Warnmeldungen können bei unzureichenden Zugriffsrechten auf das Zielverzeichnis, (zB. wenn auf ein Windowsfilesystem recovert würde) entstehen, oder wenn vorher schon mit der Option "-R" Teile des Filesystems recovert worden sind und die recoverten Verzeichnisse sehr strengen Zugriffsrechte haben. Ein weiterer Versuch noch weitere Dateien zu recovern, könnte dann uU. in einigen Verzeichnissen auf einen Schreibschutz stoßen

Eine Auflistung aller möglichen Fehlerwarnungen.

x-------

Probleme beim Recover aufgetreten oder Hardlink konnte nicht erstellt werden.

-x------

undefinierte Probleme die Datei auf die richtige Größe zu beschneiden.

--x-----

Problem die recoverte Datei in das richtige Zielverzeichnis zu verschieben, eine solche Datei ist dann im Recoververzeichnis mit der Inodenummer im Dateinamen zu finden.

---x----

Probleme die Datei der original UserID und GruppenID zuzuweisen

----x---

Probleme beim Herstellen der original Linux-Zugriffsrechte

-----x--

Probleme beim setzen der orginal mtime und atime Zeitstempel der Datei

------x-

Fehler beim recovern der ext2/3/4 Dateiattribute (ab Version 0.1.4)

-------x

reserviert für ACL,SEL und weitere





Hardlinks
Das Programm ist bestrebt die Hardlinks wieder herzustellen. Sind bei den wiederhergestellten Dateien Hardlinks enthalten, kommt bei Programmende auf stderr eine Meldung aus der während der Ausführung des ext4magic Prozesses geführten Hardlinkdatenbank. Sie besagt entweder, es konnten alle Hardlinks wieder sauber hergestellt werden, oder es erfolgt Zeilenweise eine Ausgabe zu welcher Datei die Anzahl der Hardlinks nicht stimmt. Die Zahl bedeutet die Anzahl, das Vorzeichen. um welcher Art von Differenz es sich handelt.
In beiden Fällen sollten die entsprechenden Dateien und deren Hardlinks überprüft werden.

Hardlinks können nur innerhalb eines einzelnen Recover Laufes passend erstellt werden. Erfolgt das Recover in mehreren Einzelschritten oder mehrfach hintereinander in das selbe Recover-Verzeichnis, können die Dateinamen nicht zu den passenden Dateien eines vorherigen Recoverdurchlauf verlinkt werden.

Hardlinks können von den Magic-Funktionen nicht erfasst und verarbeitet werden. Diese Funktionen sammeln nur bis zu diesem Zeitpunkt noch nicht gefunden Inode oder Dateien ein.



doppelte Dateinamen
können entstehen durch ein wiederholtes recovern der gleichen Datei in das selbe Ziel-Verzeichnis, aber auch durch das Vorkommen von doppelten Dateinamen in den Verzeichnisdaten. Solche Dateien werden beim Recover nicht überschrieben, sondern an den Dateinamen wird ein zusätzliches abschließendes "#" (auch mehrfach maximal 5 Mal) angehängt. Entstehen solche Dateien in einem einzigem Recoverdurchlauf, muss dann von Hand entschieden werden, welche der Dateien jetzt die Richtige sein soll. Erfahrungen zeigen, es ist oftmals die Datei mit den meisten # die Richtige.



Besonderheiten der Option "-Q"
beim Recovern kann zusätzlich die Option "-Q" gesetzt werden. (Ab Version 0.2.2 ist diese Option nur im Expert Modus nutzbar)

Bei dieser Option wird versucht die Probleme bei wiederverwendetet Dateinamen und wiederverwendeten Inode richtig aufzulösen. Dazu sind jedoch Journaldaten von den entsprechenden Verzeichnisdaten notwendig. Diese Option führt nur in speziellen Einzelfällen zu besseren Ergebnissen, global angewendet erreicht man meist das Gegenteil. Nutzbar ist die Option vor allem in Verzeichnissen in denen oft Dateien erzeugt umbenannt und gelöscht werden, und dabei gleiche Dateinamen mehrfach verwendet werden. Nähere Einzelheiten dazu sind im Abschnitt Tricks und Tipps zu finden.





Die Magic Optionen (seit 0.2.0)

Es handelt sich dabei um ein mehrstufiges Recoververfahren, das speziell für das Wiedergewinnen versehentlich rekursiv gelöschter Verzeichnisse oder des gesamten versehentlich gelöschten Filesystems entwickelt wurde. Die Idee dahinter, zuerst wird versucht mit den Inodekopien des Journals so viele Dateien wie möglich zu recovern. Alle Datenblöcke die dabei recovert werden konnten, werden notiert. Anschließend werden die Metadaten ausgewertet, welche während des Löschens im Journal geschrieben wurden. Aus diesen Metadaten kann ermittelt werden, welche Datenblöcke während des Löschens als wieder frei verfügbar markiert wurden. Die Differenz zwischen den Blöcken, welche während des Löschens markiert wurden und den Blöcken die schon im ersten Schritt recovert worden sind, müssen jetzt alle Datenblöcke der Dateien enthalten, die nicht aus den Inodekopien wieder hergestellt werden konnten.


Diese Datenblöcke werden in einem anschließenden weiteren Programmteil untersucht, um mit Hilfe von bekannten Dateiheadern und einprogrammierten weiteren Dateieigenschaften zu versuchen die gelöschten Dateien so wieder zu finden und zu recovern. Als Datenbasis und Untersuchungsroutine werden hierbei Funktionen und die Datenbank des Linux Befehls file verwendet. Die Library die dabei genutzt wird, nennt sich libmagic und ist letztlich auch Namensgeber für diese Optionsgruppe und schon in der Namensgebung von ext4magic eingegangen.

Somit ergibt sich eine Kombination von 2 Recoververfahren, zuerst über Inodekopien und anschließend noch ein Filecarving mit ähnlicher Arbeitsweise wie sie auch in vielen anderen Recoverprogrammen genutzt wird. Im Gegensatz zu den meisten Recoverprogrammen, welche die Filesystemmetadaten weitestgehend ignorieren und damit dann auch defekte Filesysteme und viele unterschiedliche Filesysteme recovern wollen, geht die Magic Funktionen von ext4magic sehr speziell und genau auf die Filesystemeigenschaften und die Metadaten ein und verwendet zur Steuerung zusätzlich noch Journaldaten.


Dieses Verfahren hat einige Vorteile ist allerdings in der Anwendung auf ein funktionierendes Filesystem sowie brauchbare Journaldaten angewiesen. Es arbeitet nur zuverlässig für den speziellen Zweck für den es konzipiert wurde. "Ein großer Löschvorgang war das Letzte das im Filesystem passiert ist". Die default Einstellungen sind optimiert auf einen Löschvorgang der nicht länger als 5 Minuten gelaufen ist. Das sollte für die Folgen eines versehentlich gestarteten "rm -rf ....." ausreichen. In allen weiteren Fällen muss die AFTER-Time manuell kurz vor den Beginn des Löschvorganges gesetzt werden. Das ist zB notwendig wenn die Dateien während eines recursiven move aus dem Filesystem heraus verschoben wurden, und somit erst gelesen und dann gelöscht wurden, aber im Zielverzeichnis nicht oder nicht vollständig angekommen sind. Dieses wird wohl länger als 5 Minuten gedauert haben.
Der Löschvorgang sollte möglichst die letzte Aktion im Filesystem gewesen sein, danach das Filesystem umounten und möglichst nicht wieder mounten und schon gar keinen fsck ausführen lassen. Geeignet ist diese Funktion insbesondere dann, wenn wichtige Dateien, Bilder und Dokumente gelöscht wurden und möglichst alle/viele davon wiederherstellt werden sollen.


Vorerst gibt es eine Magic-Scanner-Stufe nur für ext3. (eine verbesserte und schnellere Version ist in Entwicklung und für ext4 aktuell in 0.3.0-pv2 enthalten). Die magische Funktion hat in der aktuellen Version eine breite Unterstützung für die meisten gebräuchlichen Bild-, Audio- und Video Dateitypen, kennt viele Archive- und Kompressionsformate, kann Open Office Dokumente, HTML, und PDFs und vieles mehr recovern. Allein die nackte magische Funktion braucht keinen Vergleich mit anderen File Carving Programmen zu scheuen, und bei ext4magic sind noch Recoverstufen vorgeschaltet, die es der magischen Funktion bedeutend leichter machen, Dateien anhand ihrer Datenblöcke zu erkennen.





Benutzung der Magic Funktionen

Ext4magic kennt hierbei 2 Optionen :
-M diese Option ist dann anzuwenden, wenn das komplette Filesystem gelöscht wurde.
Die Option -m ist gedacht für den Fall, dass nur Teile des Filesystems gelöscht sind.


Zusätzlich kann noch mit der Option "-d DIRECTORY" das Verzeichnis angegeben werden, wohin die Dateien zu recovern sind. Eine Verwendung der Option "-j JOURNALKOPIE " ist ebenfalls möglich. Als Zeitoptionen könnte optional die "-a AFTER-Zeitmarke" angegeben werden, diese muss unmittelbar vor dem Beginn des Löschvorganges gesetzt sein. Wird diese Zeitmarke nicht mit angegeben, versucht ext4magic den richtigen Zeitpunkt vor dem letzten Löschvorgang aus den Filesystemdaten selbst herauszufinden. (letzte registierte Löschung -5 Minuten siehe auch ). Alle anderen Optionen werden ignoriert oder führen beim Programmaufruf zu Fehlermeldungen.



Typischer Aufruf von ext4magic nach dem kompletten Löschen eines Filesystems 

ext4magic /dev/sda6 -M

bzw. wenn das Zielverzeichnis für die recoverten Daten noch mit angegeben werden soll 

ext4magic /dev/sda6 -M -d /mnt/RECOVERVERZEICHNIS


Die recoverten Dateien werden wie gewohnt im RECOVERDIR/ Verzeichnis abgelegt. Im ersten Schritt werden jetzt dabei Dateien analog den Optionen "-R" bzw "-r" ausgehend vom Rootverzeichnis des zu untersuchten Filesystems aus recovert. Die Dateien die aus dem Inodekopien gewonnen werden können, habe weitestgehend ihre original Dateieigenschaften und Rechte.

Nachdem dieser Schritt durchlaufen ist, schließen sich weitere Recoverstufen an. Dazu werden zusätzlich bei Bedarf noch 3 Verzeichnisse im RECOVERDIR/ angelegt, um die so wieder gewonnen Dateien aufzunehmen.


MAGIC-1 : dort befinden sich Teile des Dateibaumes die durch fehlende Inodekopien von Verzeichnissen nicht beim recovern des Verzeichnisbaumes gefunden wurden.


MAGIC-2 : dort befinden sich einzelne Dateien die durch fehlende Inodekopien von Verzeichnissen nicht beim recover des Verzeichnisbaumes gefunden wurden.
Neu ab Version 0.2.4 / 0.3.0-pv2 werden hier auch eventuell gefundene Dateien recovert, von denen Inodecopien in den Löchern des Journals gefunden wurden. Von diesen Dateien ist die Inodenummer nicht bekannt und damit auch kein Dateiname und auch kein Löchzeitpunkt zu ermitteln. Doch diese Dateien sind gelöscht und wurden von vorherigen Recoverstufen nicht recovert. Sie bekommen von ext4magic automatisch beim Recover dann Inodenummern größer als die maximale Inodeanzahl des Filesystems im Dateinamen zugeordnet.

Die Dateieigenschaften in beiden Verzeichnissen ist ähnlich der Dateien im Verzeichnisbaum, mit 2 Ausnahmen: Die Dateinamen haben das Muster "<NR>", wobei die NR die ursprüngliche InodeNummer darstellt. ( Vorsicht mit diesen Dateinamen, sie müssen auf der Konsole mittels Quotierung angegeben werden. )
Da der Dateitype der Dateien in diesem Verzeichnis nicht aus den Dateinamen hervor geht, sollte man in diesem Verzeichnis zuerst immer einmal mit "file" eine "Sichtinvertur" vornehmen, und anschließen die interessanten Dateien umbenennen, bevor man sich den Inhalt der Dateien mit einem Programm anzeigen lässt. In neueren Versionen werden die Dateien hier entsprechend ihres wahrscheinliches Inhaltes mit Fileextensionen versehen und in Verzeichnissen vorsortiert abgelegt.

Der zweite Unterschied würde Hardlinks betreffen, diese können hier nicht mehr richtig aufgelöst werden, so das in dieser Recoverstufe auf die Wiederherstellung der Hardlinks komplett verzichtet wurde.


MAGIC-3 : Hier befinden sich die Dateien die durch das Scannen der Datenblöcke unter Zuhilfenahme von libmagic.so gefunden wurden. Die Dateien dort haben als Dateinamen eine Zahl und eventuell eine passende Extension. Die Zahl ist die Anfangsblocknummer der Datei im original Filesystem. Die Dateien werden in Unterverzeichnissen entsprechend des Typs angelegt, den libmagic.so glaubt in den Daten erkannt zu haben und ist größtenteils identisch der MIME-Typen Einteilung. Die Qualität dieser Dateien kann nicht garantiert werden. Es ist und bleibt immer auch ein bisschen Zufall, ob eine Datei hier richtig erkannt und auch auf die richtige Dateilänge zugeschnitten werden kann. Für ext3 und viele Dateitypen ist eine einfache Spezifizierung entwickelt worden, so das ein Großteil sehr häufiger Dateitypen mit guter Trefferquote richtig wieder hergestellt werden können. Bei einigen Dateitypen sind gegebenenfalls bei der Überprüfung der Dateien noch kleine Korrekturen notwendig damit die recoverten Dateien einwandfrei funktionieren. siehe Tricks&Tipps

Hauptsächlich sollten sich unterhalb von MAGIC-3 Dateien befinden, die während des untersuchten Löschvorganges gelöscht wurden. Dazu wird versucht aus Kopien von Metadaten aus dem Journal die Informationen zu gewinnen, welche Datenbereiche beim Löschvorgang frei gegeben worden sind. In wie weit diese Vorauswahl wirklich funktionieren kann, ist abhängig vom Inhalt des Journals. Da es auch möglich und wahrscheinlich ist, dass sich von einigen Dateiabschnitten keinerlei Metadaten vor dem Löschzeitpunkt im Journal befinden, müssen dann solche Dateiabschnitte trotzdem komplett bearbeitet werden. Dabei werden dann dort auch mehr oder weniger viele Dateien gefunden und wieder hergestellt, die schon länger gelöscht sind. Erste Tests zeigen jedoch, ext4magic recovert wesentlich weniger solcher alten Dateien als andere gängige Recovertools.


Als Datenbasis für den Scanner wird derzeit die default magic-Datenbasis des file-Befehls verwendet. Sollten sich hier zwischen den einzelnen Distributionen sehr große störende Unterschiede ergeben, wird wohl ext4magic eine eigene magic-Datendatei erhalten müssen. Die Tests in der derzeitigen Entwicklungsphase zeigen zwar das mit einer speziellen Magic-Konfiguration der eine oder andere Filesystemtype noch zusätzlich erkannt werden könnte, es aber derzeit generell nicht notwendig ist eine eigene Konfiguration speziell für ext4magic zu pflegen.
Es hat sich jedoch herausgestellt: Versionen von libmagic aus "file" kleiner V5.04 haben Speicherprobleme die ext4magic zum Absturz bringen können. Zum stabilen Betrieb muss darum file-5.04 oder neuer installiert werden. (derzeit ist bis einschließlich Version file-5.06 getestet)


Die Geschwindigkeit mit der ein Filesystem mittels der magischen Funktion recovert werden kann, ist von sehr vielen Faktoren abhängig und kann nicht wirklich mit anderen Recovertools verglichen oder gegenübergestellt werden. Es kann sehr schnell gehen wenn sehr viele Dateien schon in den ersten Stufen gefunden werden. Die letzte Stufe kann aber auch durchaus um den Faktor 10 länger dauern, als andere Recovertools für einen Recover des selben Filesystemes benötigen würden. Oft ist zu beobachten, dass das Recover in Wellen abläuft. Eine Zeit lang werden gar keine Dateien gefunden, (Hier bitte Geduld, das ist okay) und anschließend werden dann massig Dateien innerhalb kürzester Zeit gefunden. Dieses ist begründet im der Art und Weise wie die Blöcke abgescannt werden. Intern werden Datenbereiche bei Bedarf 2 mal gescannt, wobei jeweils nach anderen Kriterien gesucht wird. Lange Laufzeiten entstehen vor allem, dann wenn größere Datenbereiche nicht recovert werden können, dieses können sehr viele oder einfach nur große nicht unterstützte Dateiformate sein, längst gelöschter Dateischrott der mangels passender Journaldaten nicht vom Recover ausgeschlossen werden kann, Dateien die durch starke Fragmentierung nicht sauber erkannt werden, aber auch größere Dateiabschnitte aus der Mitte oder dem Ende von Dateien wenn der Dateianfang einfach nur sehr spät während des scannens gefunden wird. Diese Funktion kann und wird Dateien finden und richtig zusammensetzen die von anderen Tools nicht gefunden werden, sie ist aber extrem rechenintensiv und damit sehr langsam. Es kann das Ergebnis des Recovers während der Laufzeit dieser Funktion schon untersucht und bearbeitet werden. Brechen sie ext4magic ab, wenn es zu lange dauert oder die wichtigen Dateien schon gefunden sind. Für ext4 wurden die Funktionen erweitert und verbessert was auch bei ext4 spürbare Geschwindigkeitsvorteile in dieser Funktion zu Folge hat. Geplant ist die neu entwickelten Funktionen, welche derzeit nur auf ext4 funktionieren auch für ext3 anzuwenden. Voraussichtlich ab Version 0.4.x wird auch ext3 dann die verbesserten Funktionen mit einen enormen Geschwindigkeitsgewinn benutzen.



Was können die Magic Funktionen und was nicht

Prinzipiell müssen die Dateien von "file" erkannt werden, sonst können sie nicht recovert werden. file versucht möglichst viele Dateitypen an möglichst wenige Eigenschaften zu erkennen- und es liegt auch hin und wieder mal daneben. ext4magic profitiert von diesen Eigenschaften und kann damit sehr viele Dateientypen erkennen und recovern, aber hat damit auch einige Probleme der Fehlinterpretationen. Einige wenige sehr seltene und auch kaum gebräuchliche einfache Dateitypen, welche zu sehr vielen Fehlinterpretationen bei den Datenblöcken geführt habe, mussten vom Recover ausgeschlossen werden. Ursache für die Fehlinterpretation war meist, "file" versucht diese File Typen an nur ein oder 2 Byte am Dateianfang zu erkennen. Bei der Anwendung auf die rohen Datenblöcke des Filesystems gibt das dabei dann zu viele falsche Treffer.
Es wird versucht mit heuristischen Methoden aus den Datenblöcken wieder Dateien zusammen zu bauen, dieses wird oft funktionieren, jedoch nicht in jedem Fall immer zuverlässig. Andere Programme nutzen eventuell auch noch genauere Methoden und prüfen Block für Block in dem sie zB. den Datenstrom innerhalb der Datei und verfolgen oder überprüfen. Ext4magic macht dieses bei einigen Dateitypen auch, bei ext3 ist dieses nicht zwingend über die gesamte Dateilänge hinweg erforderlich. Aber es sind nur wenige Dateitypen bei denen dieses mit einem vertretbaren Aufwand zu programmieren ist. Dafür wird bei ext4magic aber versucht auch solche Dateien zu recovern, von denen überhaupt kein Algorithmus bekannt ist, mit dem jeder einzelnen Datenblock innerhalb der Datei genau überprüft werden könnte.
Des weiteren kann ext4magic zwar einiges was fragmentiert auf der Platte liegt, wieder als Datei finden und zusammenfügen. Jedoch sind kleinere Dateien mit starker Fragmentierung oder Fragmentierung am Anfang der Datei mit ext4magic auch nur bedingt wieder richtig herstellbar. Auch kann nicht wirklich sicher verhindert werden, das sich durch Fragmentierung nicht auch mal ein paar Datenblöcke von Dateien mischen oder irgend ein reiner Datenblock zufällig als der Anfang einer Datei interpretiert wird. Hier gibt es auch Unterschiede in den einzelnen Dateitypen. Bei einigen Dateitypen ist es leichter einen folgenden Datenblock einer bestimmten Datei 100%tig zuzuordnen, bei anderen Dateitypen ist dieses weniger gut möglich. Es wird also immer auch ein wenig Datenschrott im Ergebnis des Magic-Scanners zu finden sein. Viele Dateitypen können am Ende mehr oder weniger viele Nullen haben. Für einige der wichtigsten und häufigsten Dateien konnte eine Funktion geschrieben werden, die das beim Recover versucht zu korrigieren, aber längst nicht für alle Dateitypen. Es ist also möglich das einige recoverte Dateien nur deshalb nicht sauber zu öffnen sind, nur weil ihnen am Ende eine oder zwei NULLen fehlen. Anderen Dateitypen wird mit einer solchen Funktion eine bestimmte Anzahl von NUllen beim Recover automatisch angehängt. Damit werden Dateien recovert, die eventuell ab und zu auch mal ein paar Byte zu groß sind, sich aber dennoch mit gebräuchlichen Programmen meist problemlos öffnen lassen. siehe auch Tricks & Tipps
Durch die zum Vergleich mit anderen Recovertools vollkommen andere Arbeitsweise können auch einige Dateien gefunden werden, welche mit anderen gebräuchlichen Tools derzeit nicht wiederherstellbar sind oder die dort nur teilweise wieder brauchbare Dateien ergeben. Eine 100%tige Ausbeute und eine 0%ige Fehlerrate ist bei den Magic Funktionen von ext4magic nicht die angestrebte Messlatte.

Ext4magic wird innerhalb der Magic-Funktion nur die Datenblöcke berücksichtigen von denen sich der Löschvorgang noch im Journal befindet. Bei einem heute typischen default Filesystem wird es beim löschen von geschätzt mehr als 400000 Dateien zu einem Überschreiben des Beginn des Löschvorganges kommen. Genauer erklärt ist das auf der Journalseite. In diesen Fällen ist es wahrscheinlich, dass die Dateien die zuerst gelöscht worden sind nicht gefunden werden.







derzeitiger Entwicklungsstand der Magic Funktionen





Expert Mode (neu ab ext4magic 0.2.1)

Für seltene Spezialfälle wird ext4magic einige Optionen und Funktionen erhalten mit denen versucht werden kann, das Unmögliche eventuell doch noch in Reichweite zu bekommen. Diese Funktionsgruppe ist per default Einstellung nicht aktiv, und die Verfügbarkeit muss schon beim Kompilieren mittels 

./configure --enable-expert-mode

aktiviert werden. Mit ihrer Hilfe soll die Möglichkeit geschaffen werden den Funktionsumfang von ext4magic auch bei bestimmten Beschädigungen an der Filesystemstruktur anzuwenden und so auch mehr oder weniger viele Daten nach typischen Filesystembeschädigungen noch retten zu können. Die ersten dieser Funktionen sind mit Version 0.2.1 eingeführt worden, und erlauben den Zugriff auf Filesysteme die am Anfang "moderat und begrenzt beschädigt" sind. Ab Version 0.2.2 kann auch bei katastrophalen Beschädigungen durch teilweises Überschreiben des Filesystems noch Dateien aus dem defekten Filesystem heraus recovert werden.
Otto der Normallinuxer wird mit einiger Wahrscheinlichkeit solche Funktionen nie benötigen. Ein wenig Hintergrundwissen und gezielte Hilfestellungen sind auf der Expert-Mode Seite am Entstehen.







Häufiges Benutzungsproblem: scheinbar macht ext4magic nichts

Häufig scheint bei Usern welche das erste mal ext4magic benutzen möchten das Problem aufzutreten, dass ext4magic scheinbar nur ein paar wenige Zeilen Ausgabe produziert und sich dann sofort wieder beendet ohne wirklich gearbeitet zu haben. Es gibt 2 mögliche Ursachen für dieses Verhalten:

Sie benutzen ext4magic nicht mit Rootrechten. 

Aus Sicherheitsgründen musste die Nutzung von ext4magic ohne Rootrechte unterbunden werden. Diese Abweisung erfolgt von ext4magic jedoch kommentarlos.

Sie untersuchen ein komplett gelöschtes Filesystem und der Löschzeitpunkt liegt schon mehr als 24 Stunden zurück

Die Defaulteinstellungen von ext4magic sind auf die letzten 24 Stunden vor dem Programmaufruf eingestellt. Liegt eine Löschung schon länger zurück und sie benutzen keine passenden Zeitoptionen, kann ext4magic nichts im Filesystem finden. (Siehe dazu auch Zeitoptionen)





Strategien Tipps und Tricks

Eine kleine Sammlung von Howtos und Erfahrungen mit ext4magic





Manpage

Die originale Manpage wird zusammen mit dem Programm aus dem Quelltext heraus installiert. Sollte Bedarf bestehen diese Manpage zu lesen ohne sie zu installieren, die folgende beiden Kommandos bringen die Manpage von ext4magic aus dem Quellcode auf der Konsole zur Ausgabe. 

nroff -man  src/ext4magic.8
man -l src/ext4magic.8

Eine deutsche Version der Manpage von ext4magic im Wiki-Format befindet sich in dieser Dokumentation



Links und weiterführende Informationen





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