Verlorene Dateien wiederherstellen ext3 ext4

Wird eine Datei gelöscht, dann bleiben die Datenblöcke dieser Datei von der Löschung unberührt. Die Löschung der Datei erfolgt in den Verwaltungsdaten (Inode) der Datei, sowie in den Verzeichnissen, wo die Inodenummer mit dem Dateinamen verknüpft wird. In einem ext3/4 Filesystem werden die Daten in der Inode soweit gelöscht, das es schwierig wird eine versehentliche Löschung wieder rückgängig zu machen. Lange Zeit war das etwas für Spezialisten und dem Filesystem Debugger. debugfs

Da es trotz größter Vorsicht hin und wieder mal jedem passieren kann, an dieser Stelle ein paar Hinweise und Links was heute auf ext3/4 möglich und machbar ist. Was man wissen sollte, und wie man vorgehen kann.

---

Gelöschte Dateien auf einem ext3 oder ext4 Filesystem wiederherstellen

Ein paar Einleitende Hintergrundinformationen

Um die Probleme und Möglichkeiten die beim Herstellen von gelöschten Dateien bestehen einigermaßen zu verstehen, sollte man folgendes ansatzweise wissen. Die Gesamtheit einer normalen Dateien bestehen im ext2/3/4 Filesystem aus mehreren Einzelkomponenten

die Datenblöcken 

• dieses sind einzelne Blöcke die den Inhalt der Datei, also die reinen Daten, aufnehmen müssen. Je größer die Datei, umso mehr solche Datenblöcke gehören zu dieser Datei.

die Inode 

• hier stehen die Eigenschaften der Datei, wie Dateityp, Zugriffsrechte, User und Gruppe, Dateigröße usw. Die Inode adressiert aber auch über eine Art Zeigersystem die Datenblöcke. Das bedeutet, über die Inode sind alle Datenblöcke die zur Datei gehören erst auffindbar. Bei großen Dateien reicht die direkte Adressierungsmöglichkeit der Inode nicht aus und es werden zwischen die Datenblöcke weitere Adressblöcke geschrieben, die die Adressierung der Inode durch indirekter Adressierung erweitern. Die Daten von großen Dateien werden so sequentiell auf der Festplatte dann durch gelegentliche zusätzlich eingeschobene Verwaltungsblöcke unterbrochen. Große Dateien stehen also nicht in einem Stück auf der Festplatte, da Verwaltungsdaten dazwischen eingeschoben sind.

der Verzeichnisseintrag 

• das ist ein Eintrag in einer Verzeichnisdatei. In diesen Verzeichnissdateien wird eine Zuordnung von genau einem Dateinamen zu genau einer Inode gemacht. Hier bekommt eine Datei ihren Namen. Die einzelnen Einträge für die Dateien bilden innerhalb der Verzeichnissdateidaten eine verkettete Liste, mit deren Hilfe alle Dateien dieses Verzeichnisses aufgelistet/angesprochen werden können.

die Kette der Verzeichnisse 

• Auch die einzelnen Unterverzeichnisse sind in den Direktories mit einem Namen und der Inode der jeweils eingetragen. So bilden sie eine Art verketter Liste von der Wurzel des Dateisystems bis zum Verzeichnis in dem dann die Dateinamen enthalten sind. Aus den Verzeichnisnamen in dieser Kette wird der Path für diese Datei im Filesystem gebildet, und dieser zusammen mit dem Mountpoint ergibt dann die absolute Adresse einer Datei im gemounteten Filesystem.

Änderungen am Filesystem werden in aller Regel nicht momentan ausgeführt. Das System nimmt den Filesystem Cache und buffert die Daten temporär. Automatisch wird ein "sync" alle paar Sekunden dann die Daten wirklich auf die Platte schreiben. Wird zB eine Datei verändert und unmittelbar danach sofort die ganze Datei gelöscht, dann wird die Änderung der Datei eventuell gar nicht erst auf die Platte geschrieben, sondern nur die Löschung. Wiederherstellen können wir nur das, was auf der Platte steht und nicht das was niemals auf die Platte geschrieben wurde.

Beim Löschen von Dateien in ext3/4 passiert nun vereinfacht folgendes:
es werden in der Inode die Zeiger auf die Datenblöcke gelöscht. Die Inode bekommt einen Zeitstempel als Lösch-Markierung, die Datenblöcke werden als "Frei verfügbar" markiert, und in den Verzeichnisdateien werden die Einträge mit dem Dateinamen und der dazugehörigen Inode ausgekettet (nicht gelöscht). Somit sind diese Dateinamen dann im Dateisystem bei normalen Zugriffen nicht mehr sichtbar. Es werden also nicht alle Spuren einer Datei beim Löschen endgültig beseitigt, im Gegenteil es wird gar nicht erst versucht. Es wird nur dafür gesorgt das sie nicht mehr zu sehen und zu finden ist und die belegten Datenbereiche dieser Datei wieder frei verfügbar sind. Bei ext3/4 ist im Gegensatz zu ext2 aber genau die Entfernung der Verlinkung in der Inode zu den Datenblöcken der Datei, ein Problem das ein rückgängig machen einer ausgeführten Löschung, ausgesprochen schwierig gestaltet.

---

wiederherstellen von versehentlich gelöschten offene Dateien

Dateien aus dem /proc Verzeichnis wiedergewinnen

Gelegentlich kann es vorkommen, und man löscht eine Datei versehentlich und merkt sofort: "Hilfe diese Datei wird benötigt und ich habe sie auch gerade noch in einem anderem Programm in Benutzung".

Rechtzeitig bemerkt ist so was erst einmal nur Halb so schlimm. Solange eine Datei noch von einem Prozess geöffnet ist, existiert im Rechner noch der Verweis auf die Datei, und der entsprechende Prozess kann weiter mit dieser Datei arbeiten. In den Verzeichnissen ist die Datei schon nicht mehr sichtbar. Andere Prozesse können diese Datei jetzt also auch nicht mehr öffnen weil sie nicht mehr zu finden ist. Sobald der letzte Prozess, der auf eine solche schon gelöschte Datei, zugreift diese Datei schließt, oder dieser Prozess beendet wird, erst dann wird diese Datei dann endgültig im Filesystem gelöscht. Dieses Verhalten kann man zum Beispiel auch bemerken, wenn man versucht eine überlange aktuelle Logdatei zu löschen. Man hat eine riesengroße Datei zwar gelöscht, sieht sie auch nicht mehr mit "ls", aber der Speicherplatz dieser Datei wird einfach nicht freigegeben. Die Logdatei ist dann immer noch von einem Prozess geöffnet der hier nach wie vor in die scheinbar schon gelöschte Datei weiter schreibt. Die Datei kann also durchaus noch weiter anwachsen. Erst wenn dieser Prozess beendet wird, dann wird der Plattenplatz den diese Datei belegt hat, wirklich freigegeben.

Eine solche Datei kann man mit dem Befehl lsof finden.

 rob@dhcppc0:~/Dokumente> lsof -a +L1 /home
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NLINK    NODE NAME
more    5139  rob    3r   REG    8,6    72830     0 1143264 /home/rob/Dokumente/orig.txt (deleted) 

Wir sehen die Datei ist vom Befehl "more" mit der PID 5139 in Arbeit und wird als "deleted" angezeigt. In der Spalte FD finden wir "3r" Das Bedeutet: dieser Prozess greift mit dem Filediskriptor Nr 3 lesend (r) zu. "5w" würde dann also Filediskriptor 5 hat schreibenden Zugriff auf diese Datei.

Diese Datei können wir jetzt im /proc Verzeichnis finden.

rob@dhcppc0:~/Dokumente> ls -l /proc/5139/fd/*
lrwx------ 1 rob users 64  9. Dez 19:09 /proc/5139/fd/0 -> /dev/pts/0
lrwx------ 1 rob users 64  9. Dez 19:09 /proc/5139/fd/1 -> /dev/pts/0
lrwx------ 1 rob users 64  9. Dez 19:09 /proc/5139/fd/2 -> /dev/pts/0
lr-x------ 1 rob users 64  9. Dez 19:09 /proc/5139/fd/3 -> /home/rob/Dokumente/orig.txt (deleted)

Allerdings, können wir hier auch nicht direkt auf die schon gelöschte Datei zugreifen, aber wir können ihren Inhalt immer noch auslesen und diesen wieder als Datei neu schreiben. Dabei würde jetzt eine neue Datei mit gleichem Namen und gleichem Inhalt angelegt.

rob@dhcppc0:~/Dokumente> cat /proc/5139/fd/3 > /home/rob/Dokumente/orig.txt
rob@dhcppc0:~/Dokumente> ls -l /home/rob/Dokumente/orig.txt
-rw-r--r-- 1 rob users 72830  9. Dez 19:24 /home/rob/Dokumente/orig.txt

Das ganze funktioniert auf diese Weise solange wir es mit "nur zum Lesen geöffnet" Dateien haben. Ist diese Datei zum Schreiben geöffnet, können wir so auch jederzeit eine Momentaufnahme dieser Datei erzeugen. Doch danach wird der Prozess eventuell weiterhin in die alte, schon gelöschte Datei, weiter schreiben. Diese Änderungen werden dann natürlich nicht mehr in unsere neu angelegte Datei registriert. Wir haben ja nur eine Momentaufnahme als Kopie. So kann es hier sein, das wir die letzten Änderungen an einer solchen Datei verlieren. ZB bei Datenbankdateien wäre so etwas dann allerdings fatal. Hier könnte zB tail helfen, um die Datei mit allen Änderungen vollständig wieder herzustellen. Siehe auch Beispiele

---

Ich habe gerade all meine Daten gelöscht, Erste Hilfe

Selbstverständlich hat ja jeder immer ein aktuelles Backup all seiner Betriebssysteme und all seiner Daten und hat es auch schon erfolgreich getestet, dass er damit jederzeit alles wiederherstellen kann. Deshalb das folgende hier nur theoretischer Art. ;-)
Jeder hat etwas anders auf dem Rechner und nicht jeder Rechner hat die selbe Nutzung, deshalb erstmal allgemeine Vorgehensweise unmittelbar nach dem man bemerkt hat, "hier sind wohl eben versehentlich wichtige Daten gelöscht worden". Ziel ist es hier sicherzustellen, das man morgen wieder an die Daten kommt, die man heute gelöscht hat, auch wenn man heute noch überhaupt keine Ahnung davon hat, wie das gehen soll.

1. zuerst möglichst keine vorschnellen unüberlegten Aktionen starten. Nicht ausschalten, nicht Platte ziehen, keine größeren Programme, Scripte oder Befehle nach starten
2. besser erstmals 3 Minuten lang nur den Kopf benutzen und versuchen überhaupt erst mal zu begreifen, was eventuell schief gelaufen sein könnte: wann ging es noch ; was habe ich "falsch" gemacht ; was könnte betroffen sein? Letzte Befehle anschauen, letzte Fehlermeldungen verstehen.
3. Was hier zuerst einmal ganz wichtig ist: jetzt unbedingt verhindern das dieser Datenstand automatisch als Backup gesichert wird und uns damit vielleicht noch das letzte vollständige Backup überschreibt.
4. als nächstes mit "kleinen Befehlen" möglichst herausfinden: Geht überhaupt noch was? Welches Filesystem, welcher Verzeichnisbaum ist betroffen? was sind/waren dort für Dateien und Daten? Welche Prozesse/User/Dienste/Server greifen dort zu, welche davon könnten dort auch schreiben? Kann/darf ich diese Programme beenden, oder noch schlimmer, muss ich sie etwa beenden, weil ihnen Dateien unter dem Hintern weggelöscht wurden und sie jetzt deshalb nur noch Fehler produzieren und die Logdateien vollmüllen?
5. Wichtig nachdem klar ist was in etwa alles gelöscht wurde: das entsprechenden Filesystem so gut es geht vor weiteren Schreibaktionen schützen: Wenn möglich Rechner beruhigen (zB Singleusermodus wenn man genügend Konsolenrfahrung dafür hat), ansonsten: Programme die schreibend zugreifen möglichst beenden, nicht benötigte Programme und Fenster schließen, keine weiteren Programme starten die auf dieses Filesystem zugreifen könnten. Bei betroffenen Homeverzeichnissen eventuell, neuen User anlegen dessen Home dann auf dem Rootfilesystem angelegt wird und als dieser User weiterarbeiten, Ziel ist möglichst das entsprechende Filesystem auf readonly zu remounten noch besser wenn möglich das Filesystem komplett umounten. Vorsichtshalber in der /etc/fstab Schreiberlaubnis für die betroffene Partition auch vorläufig entfernen.
6. Was oftmals übersehen wird. Es handelt sich um ein Journalfilesystem. Das Journal wird auch weiterhin benutzt auch wenn man nichts in das Filesystem schreibt. ZB. wenn Dateien gelesen werden, dabei wird ein neuer a-time Zeitstempel in die Inode eingetragen. Auch solche Aktionen laufen über das Journal. Würde jetzt zB mit einem "find" der Rest des Filesystems durchsucht werden, würde je nachdem wie viel vom Filesystem nach dem Löschen noch übrig ist, eventuell eine ganze Menge ins Journal geschrieben. Jede dieser Schreibaktionen im Journal wird dabei alte Journaldaten überschreiben. Und es gibt Recoverprogramme die aus alten Journaldaten hervorragend wiederherstellen können. Also sollte man sich die alten Journaldaten nicht noch unnötig überschreiben, wenn man ein solches Programm nutzen möchte. Je früher man das Filesystem oder zumindestens das Journal jetzt aushängt und nicht weiter benutzt, desto mehr Dateien werden solche Programme finden können.
7. Informationen sammeln: Parititionsgrößen, Mountpoints, Filesystemtyp, wie viel ist im Moment belegt, wie viel könnte es vorher gewesen sein, Datentypen, Homeverzeichnisse anderer User betroffen? Dann diese auch informieren und auch dort Informationen sammeln. Wenn möglich welche Verzeichnisstruktur war auf der Platte, bzw. was ist davon verschwunden. Wo habe ich im Rechner eventuell noch Platz, um temporär Dateien zwischenzuspeichern. Eventuell muss man sich Prioritäten setzen: was brauche ich an Dateien unbedingt wieder; auf was kann ich notfalls verzichten; was wäre eventuell ganz unwichtig.
8. Ist das betroffene Filesystem soweit beruhigt, dass möglichst nichts mehr neu geschrieben werden kann (auch nicht nach einem eventuellem reboot) und die wichtigsten Informationen eingesammelt sind, erst dann geht es weiter.
9. Möglichst an dieser Stelle jetzt eine Kopie der Partition als Image oder auf eine andere Platte erzeugen. (1 zu 1, nicht komprimiert). Eine solche Kopie kann mit dd erzeugt werden, wichtig hierbei die Partition sollte möglichst umountet sein, maximal aber Readonly. Mit einer solchen Kopie zB auf einer USB-Platte hat man jetzt theoretisch unendlich viel Zeit und unendlich viele Versuche die wichtigen Dateien wieder herzustellen. Dazu muss aber entweder das Original, oder die Kopie vom Original, von jeglichen Versuchen kategorisch ausgeschlossen werden. Dieses wird immer nur zum Lesen benutzt und zwar um wieder eine neue Kopie davon zu machen, für den nächsten Versuch die Dateien wieder herzustellen.

Zum Datenwiederherstellen benötigt man mindestens 3 Dinge: Internetzugang, um an die richtigen Howtos und die Programme zu kommen, genügend Plattenkapazität, um die wiederhergestellten Dateien schreiben zu können, und reichlich Zeit. Erfahrungsgemäß fehlt einem immer eines. :-) man wird es aber trotzdem brauchen.

---

Dateien anhand ihres Type mit einem Flächenscan aus den Datenblöcken wieder gewinnen

Die nackten Datenblöcke der Dateien bleiben als solche bei den allermeisten Filesystemen auch beim Löschen vollkommen intakt auf der Festplatte zurück. Man muss eine Platte schon gezielt überschreiben, damit man nicht mehr an alte Dateien herankommt. Liest man die gesamte Partition Block für Block aus und schaut sich die einzelnen Blöcke insbesondere den Blockanfang an, wird man dort an bestimmten Eigenschaften den Beginn von bestimmten Dateitypen erkennen können. Ist die Datei größer als die Blockgröße, dann wird man wahrscheinlich im nächsten Block die Fortsetzung dieser Datei finden. Auch das Ende vieler Dateien kann man erkennen. Meist ist der Rest hinter einer Datei mit Nullen bis zum Blockende gefüllt. Es ist also möglich hintereinander liegende Datenblöcke zu Dateien zusammen zu bauen. Wenn das ein einigermaßen intelligentes Tool macht, und dieses auch noch ein bisschen Ahnung vom Filesystem hat, dann hat man sogar die Chance auch Dateien aus Blöcken wiederzufinden und zusammen zu bauen, die auf der Platte fragmentiert vorliegen. Tools die so nach verlorenen Dateien suchen gibt es eine ganze Menge.

Das Problem dabei. Es werden in aller Regel nicht nur die verlorenen Dateien wieder gefunden die man benötigt, sondern auch solche, die man nicht verloren hat, sowie jede Menge Kopien davon und jede Menge Dateien die man schon vor ewiger Zeit gelöscht hat, und auch mehr oder weniger viele, die mittlerweile fehlerhaft oder komplett defekt sind. Ein gutes Tool ist jetzt in der Lage bei einigen Dateitype, insbesondere bei Dateien welche Metadaten in sich bergen den Dateinamen und einige Eigenschaften wieder richtig zu setzen. Für einige Dateitypen wird eventuell noch der gefundenen Datei wieder eine richtige Dateiendung gegeben, die auf den wahrscheinlichsten Datentyp hinweist. Diese Tools sind aber nicht in der Lage den gefundenen Dateien allen ihre ursprünglichen Namen wieder zugeben, geschweige denn zu entscheiden, in welches Verzeichnis gehört die Datei und welchem User hat die Datei gehört. Nach dem Einsatz solcher Tools kann man sich nicht selten Stunden und Tage damit befassen, Dateien zu sichten, zu sortieren und ihnen neue Namen zu geben. Eventuell helfen Scripte dabei. Allerdings sind die Probleme dabei so vielfältig und in jedem Fall anders gelagert, das es dazu nicht wirklich etwas universelles gibt. Dieses Verfahren eignet sich vor allem für gelöschte Datendateien, Bilder, Musik, Dokumente usw. Der Versuch dieses Verfahren auf das Rootfilesystem anzuwenden, würde wahrscheinlich zu nichts weiter als zu Datenschrott führen.

PhotoRec

PhotoRec ist ein Tool aus TestDisk Mit seiner Hilfe ist es möglich verlorene oder gelöschte Dateien durch einen Scan des Datenträgers wiederzufinden. PhotoRec unterstützt viele Dateisysteme und ist nicht mal auf ein funktionierendes Filesystem angewiesen, kann also Dateien auch noch finden wenn das Filesystem schwer beschädigt oder eventuell neu formatiert wurde. Es kennt eine ganze Reihe von Dateitypen, die es wieder herstellen kann.

Testdisk sollte man in verschiedenen Distributionen und auf verschiedenen Hilfs- CD/DVDs finden. Unter OpenSuse sollten fertige Pakete bei Packman zu finden sein.

Die Benutzung von PhotoRec ist in diesem HOWTO wohl gut genug beschrieben, so das wir das hier gar nicht erst versuchen müssten.

Das Hauptproblem dürfte meist erst auftreten, wenn PhotoRec mit seiner Arbeit fertig ist. Es wird oftmals nicht leicht sein all die Dateien zu sortieren die dort gefunden werden. Hier und an vielen anderen Stellen i, Netz wird man sicherlich Tipps und Tricks dazu finden.

---

Die Dateien mit Hilfe alter Filesystem-Journaldaten wieder herstellen

Das Prinzip dahinter ist folgendes. ext3/4 ist ein Journalfilesystem. Bevor Änderungen an der internen Filesystemstruktur vorgenommen werden, werden diese Änderungen in einer Art Aufgabenbuch, dem sogenanntem Journal, auf die Platte geschrieben. Erst dann werden die Änderungen an dem Filesystem selbst vorgenommen. Ist die Änderung im Filesystem abgeschlossen, werden die Aufgaben im Journal als "erledigt" markiert. Damit wird gesichert, dass auch bei einem Rechnerabsturz das Filesystems konsistent bleibt und ermöglicht eine schnelle Wiederherstellung des Filesystems nach einem Absturz. In diesem Fall müssen dann nur die noch offenen Änderungen im Journal abgearbeitet werden.
Zu den Daten die dort im Journal abgelegt werden gehören die Blöcke in denen die Inode enthalten sind. Dort im Journal befinden sich also Kopien von alten Inodedaten. Und diese stehen dort oftmals einen längeren Zeitraum. Da immer ganze Inode Blöcke dort abgelegt werden, ist die Wahrscheinlichkeit sehr groß, dass man von vielen Dateien dort auch eine alte Inode findet.

Hier sind also genau die Informationen die uns zB. nach dem Löschen von Dateien fehlen würden, um eine Datei komplett wieder herzustellen. Das Problem ist jedoch jetzt die richtige Kopie einer Inode zu finden, die genau die Daten der Inode einer Datei vor dem Löschen enthält. Meist sind von Dateien mehrere, oftmals sehr viele alte Kopien dort zu finden. Gelöschte Dateinamen stehen immer noch mit der ehemaligen Inodenummer in den Datenblöcken der Verzeichnisdateien. Dort müsste der Datenblock nur roh ausgelesen werden um den ehemaligen Dateinamen und die dazugehörige Inode zu ermitteln. Von dieser Inode benötigen wir jetzt aus dem Journal die älteste Kopie die noch keinen Löschzeitstempel hat. Aus den Daten dieser Inodekopie kann jetzt über die Links zu den Datenblöcken, die Datei wieder hergestellt werden. Die anderen Eigenschaften der gelöschten Datei stehen auch in dieser Inode. Die Datenblöcke auf die diese Inodekopie verweist, sind zwar im Filesystem derzeit als "frei verfügbar" markiert, die Wahrscheinlichkeit dass sie jedoch noch nicht anderweitig benutzt wurden, ist groß. Damit könnte jetzt problemlos eine Kopie der gelöschten Datei erzeugt werden. Programme die das können sind ext3grep ; extundelete ; ext4magic

Haben wir uns eine Datei überschrieben, zB weil wir statt mit der Umleitung ">> Dateiname" (die soviel bedeutet wie, Ausgabe am Ende der Datei Dateiname weiter schreiben) mit der Umleitung "> Dateiname" (Ausgabe in Datei Dateiname schreiben), gearbeitet haben, dann könnte über das Journal auch in diesem Fall die Informationen gewonnen werden, um den alten Dateistand wieder herzustellen. Automatische Funktionen dafür gibt es in den hier vorgestellten Programmen derzeit wohl nun bei ext4magic. Mit Hilfe von ext3grep wäre es mit einigem Hintergrundwissen noch manuell möglich. Mit extundelete scheint das derzeit überhaupt nicht möglich zu sein.

---

ext3grep

Einleitung :
ext3grep ist ein Konsolenprogramm von Carlo Wood. Es wurde wohl ursprünglich aus der Not heraus entwickelt. Die allgemeine Vorgehensweise und das Prinzip sind in seinem Howto sehr schön beschrieben. Carlo Wood hatte die revolutionäre Idee aus dem Filesystem-Journal Backups von früheren Inodeblöcken die Daten zu gewinnen mit deren Hilfe die gelöschten Dateien wieder hergestellt werden können.

Vorteile :
Es können gezielt Kopien sowohl von einzelnen gelöschte Dateien, oder auch von allen als gelöscht erkannten des Filesystems mitsamt Dateinamen mit dem Pfad und original Zugriffsrechten und Zeitstempel wieder hergestellt werden. Man kann dabei den Löschzeitraum zeitlich eingrenzen, so das man gezielt nur versucht solche Dateien wieder zu gewinnen, die während diesem Zeitraum gelöscht wurden. Es kann eine Liste aller in Verzeichnisdatenblöcken gefundenen Dateinamen erstellt werden. Möglich sind auch Zeit Histogramme aus den Inodedaten, zB um die Anzahl der Löschvorgänge im zeitlichen Zusammenhang anzuzeigen. Damit ist es möglich den interessanten Löschzeitraum gut einzugrenzen. Eine Reihe von zusätzliche Optionen ermöglichen eine sehr gute und hilfreiche Informationen aus dem Filesystem und aus dem Journal für das Auffinden von gelöschten oder verlorenen Dateien auch in speziellen Problemfällen. Mit diesen Informationen ist es mit etwas Hintergrundwissen auch durchaus möglich per Hand bestimmte ältere Dateistände von Dateien wieder herzustellen. Einfaches normales Wiederherstellen einer erst kürzlich gelöschten Datei ist damit auch ohne spezielle Kenntnisse mit nur wenigen Optionen für die meisten Linuxuser fast problemlos auf der Konsole machbar.

kleine Mängel :
Das Programm arbeitet relativ langsam, da es einmalig aufwendige Scans nach allen Dateinamen über das gesamte Dateisystem macht. Größere Filesysteme haben dabei entsprechend sehr lange Laufzeiten, auch wenn nur sehr wenige Dateien wieder hergestellt werden sollen. Bei einem erneutem Aufruf von ext3grep auf dem selben Filesystem ist es dann recht flott, da die Daten nur einmalig gescannt werden brauchen und in Logdateien abgelegt werden. Es ist sehr viel im Programm starr einprogrammiert worden. Dadurch ist es nicht flexibel genug, um alle möglichen Eigenschaften des Filesystems zu berücksichtigen. ext4 Filesysteme funktionieren zum Beispiel gar nicht. Unterstützt werden nur Little Endian (Intel x86) Systeme. Das Programm wird scheinbar vom Entwickler selbst z.Z. nicht mehr ernsthaft weiterentwickelt und ist auch im Quelltext nicht sonderlich übersichtlich und strukturiert, so das auch andere Entwickler hier nur sehr schwer einen Einstieg für eine Weiterentwicklung finden werden.

Fazit (des Autor dieses Wikibeitrages) :
Einfach genial für Standard ext3, aber leider nicht flexibel genug für ext4. Geeignet für kleine und mittlere Filesysteme wenn viele Dateien wieder hergestellt werden sollen. Sehr gut geeignet auch um Informationen aus dem Filesystem für manuelles Wiederherstellen bei extremen Problemfällen zu gewinnen.

Installation von ext3grep

Einige Distributionen scheinen es per Paket oder per default zu unterstützen. Für OpenSuse müsste es bei Bedarf selbst kompiliert werden.
Benötigt werden die allgemeinen Entwicklertools mit C++ sowie die Header von e2fsprogs

Im einzelnen wären folgende Pakete mit ihren Abhängigkeiten zu installieren : gcc ; gcc-c++ ; make ; e2fsprogs-devel

Quellcodearchiv downloaden

 wget http://ext3grep.googlecode.com/files/ext3grep-0.10.1.tar.gz

Archiv auspacken

tar -xzf ext3grep-0.10.1.tar.gz

in das Verzeichnis wechseln, dort configure und make ausführen.

cd ext3grep-0.10.1/
./configure
make

Das Ergebnis ist eine ausführbare Datei namens ext3grep im Unterverzeichnis src/
Zu installieren braucht man das Programm nicht unbedingt, es reicht wenn man es in ein Arbeitsverzeichnis kopiert oder man könnte es auch dort an Ort und Stelle ausführen, wo es kompiliert wurde. Dadurch kann es, wenn man es nur einmalig benötigt, anschließend auch schnell wieder gelöscht werden.

cp src/ext3grep /TEMP/ARBEITS/VERZEICHNIS/
cd /TEMP/ARBEITS/VERZEICHNIS/
./ext3grep --help

Hinweise und Beispiele zur Benutzung

Es wird dringend empfohlen mit einer Kopie des entsprechenden Filesystems zu arbeiten. Wo das nicht möglich ist, geht es auch mit dem Filesystem selbst, nur sollte es auf keinem Fall in dieser Zeit mit Schreibzugriff eingehängt sein. Wenn man mit einer Image-Kopie vom Filesystem arbeitet, benötigt man keine Rootrechte, kann dann allerdings ohne Rootrechte auch die Dateien nicht mit ihren Orginal Zugriffsberechtigungen erstellen.
Im Arbeitsverzeichnis sollte genügend freie Plattenkapazität vorhanden sein, da dorthin die wiederhergestellten Dateien geschrieben werden.

Wenn ext3grep das Filesystem scannt, legt es im aktuellem Verzeichnis 2 Dateien an. FILESYSTEMNAME.ext3grep.stage1 und FILESYSTEMNAME.ext3grep.stage2
Diese Dateien bitte nicht per Hand manipulieren, auch wenn das noch so verlockend ist. Diese Dateien müssen jedes mal gelöscht werden (damit sie bei erneuter Verwendung von ext3grep wieder neu erzeugt werden) nachdem man das Filesystem wieder schreibend eingehängt hat oder zB ein anderes Filesystem mit dem selben Kopienamen bearbeiten will. Sonst kommt ext3grep durcheinander.

Die wiederhergestellten Dateien landen in einem Unter-Verzeichnis "RESTORED_FILES/" das ext3grep selbst anlegt. Es werden für einige Optionen Zeitangaben im Sekundenformat seit 1970 benötigt. Diese kann man zB wie folgt ermitteln, oder in der Manpage von date nachlesen.

date +%s                             #jetzt
date -d "" +%s                       #heute 0:00 Uhr
date -d "-1 day" +%s                 #gestern um diese Zeit
date -d "2009-12-10 15:28:42" +%s

Alle Befehlsoptionen anzeigen lassen, allgemeine Hilfe

./ext3grep --help

Test auf prinzipielle Unterstützung des Filesystems, auslesen des Filesystem Superblocks, (test.iso ist hier ein Filesystemimage)

./ext3grep test.iso

Ein Histogramm erzeugen, um herauszufinden, wann wie viele Dateien gelöscht wurden, Damit lässt sich der interessante Zeitbereich sehr genau bestimmen (Zeitoptionen wie oben beschrieben)

./ext3grep --histogram=dtime --after=1202351086 --before=1202351129

Alle Dateien wiederherstellen, die ab einer bestimmten Zeit gelöscht wurden

./ext3grep test.iso --restore-all --after=1260399600 

Eine Liste der Dateinamen erzeugen von denen ext3grep annimmt, sie wiederherstellen zu können

./ext3grep test.iso --dump-names

Eine einzelne ganz bestimmte Datei "Verzeichnis/Path/dateiname.txt" wiederherstellen. Der Path zur Datei beginnt mit dem Wurzelverzeichnis aus der Sicht dieses Filesystems und darf nicht mit "/" beginnen. Der Dateiname muss in der oben erzeugten Liste enthalten sein.

./ext3grep test.iso --restore-file Verzeichnis/Path/dateiname.txt

Hinweise:

1. Das Programm ist und bleibt "Beta"
2. Es geht hier nur ext3, wenn ein ext3 Filesystem mit ext4 beschrieben wurde, oder nach ext3 konvertiert wurde, wird es nicht funktionieren oder nur unzureichende Ergebnisse liefern
3. Niemals, und auf gar keinen Fall versuchen, Dateien aus dem selben Filesystem wiederherzustellen, in das man gerade die wiederhergestellten Dateien wieder hinein schreibt :-)
4. Wann immer möglich keinen Filesystemcheck nach dem Löschen und vor dem Recoverversuch durchführen, besonders keinen, wo man Fragen beantworten soll. Wenn der Rechner vor dem Recoverversuch noch rebootet oder ausgeschalten werden muss und man keine Kopie hat, prüfen ob man den Eintrag in der /etc/fstab auf readonly umändern kann und im sechtem Feld mit einer "0" den Filesystemcheck verhindern kann
5. Möglichst den Zeitraum einschränken oder genaue Dateinamen angeben, damit nicht Unmengen uralte Dateien wiederhergestellt werden.
6. Es wird mit diesen hier vorgestellten einfachen Optionen der Stand vor dem letztem Löschvorgang einer Datei hergestellt.
7. Nicht wirklich jede Datei wird sich jederzeit auch so wiederherstellen lassen, Ein Backup ersetzt dieses Tool also keinesfalls
8. Möglichst nicht erst viel im Filesystem weiter schreiben
9. Die wiederhergestellten Dateien sollten gründlich kontrolliert werden, auf Vollständigkeit und ordnungsgemäßen Inhalt
10. je nach Füllstand und Durchsatz können einzelne Dateibestandteile schon ganz oder teilweise neu überschrieben und schon wieder gelöscht sein. Daraus könnte im Einzelfall durchaus auch mal ein scheinbar ganz falscher Inhalt der wiederhergestellten Dateien resultieren.
11. Gerätedateien Pipes u.ä. werden nicht unterstützt
12. Eventuell werden ehemalige Hardlinks jetzt zu selbständigen Dateien (Auch den Hinweis über die Hardlinks im Howto lesen.)

---

extundelete

Einleitung:
extundelete ist eine Überarbeitung der Idee von ext3grep. Im Unterschied zu ext3grep benutzt extundelete die Funktionen des ext2fs library zu. Dadurch können recht schnell auch aus großen Filesystemen einzelne Dateien wiederhergestellt werden.

Vorteile :
Sehr brauchbare Laufzeiten auch in großen Filesystemen. Flexibel sowohl auf ext3 wie ext4. Analoge Funktionen und ebenfalls weitestgehende analoge Befehls-Optionen zu ext3grep. Durch die Benutzung der Libraryfunktionen erhält es automatisch die notwendige Flexibilität für eine gute Unterstützung des ext3/4 Filesystems. Unterstützung auf für Big Endian. Es können hiermit auch gezielt Verzeichnissbäume und Dateilisten wiederhergestellt werden. Das Wiederherstellen von Dateien ist ohne großartige Spezialkenntnisse von jedermann möglich. Für viele Distributionen als Paket erhältlich.

kleine Mängel :
Es sind noch längst nicht alle ursprünglich beabsichtigten Funktionen implementiert. Die Weiterentwicklung scheint mehr oder weniger eingeschlafen zu sein. Derzeit kann nur der reine Dateiinhalt wiederhergestellt werden. Nützliche Zusatzfunktionen, wie in ext3grep, sind leider derzeit nicht implementiert. extundelte ist derzeit nicht mit den aktuellsten Versionen von libext2fs (1.42) nutzbar.

Fazit (des Autor dieses Wikibeitrages) :
Projekt mit guten Potential. Einfach in der Anwendung und einige Tests und Wiederherstellungen von Dateien und Verzeichnissen sowohl auf ext3 wie ext4 begeistern jedoch, auch wenn mehr oder weniger "nur" die reinen Dateidaten mit ihrem Namen und Pfad möglich sind. Die Datendateien sind das Wichtigste, das scheint prima zu funktionieren. Leider bleiben Fragen zu Problemen selbst in den offiziellen Mailinglisten oftmals unbeantwortet.

Installation von undelete

Soweit undelete nicht als Paket erhältlich sein sollte (Einige Distributionen bieten derzeit fertige Installationspakete an), bitte immer die aktuellste Version nehmen, hier wurde die Version 0.1.8 getestet. Kompilieren ist recht einfach, ähnlich ext3grep
Benötigt werden genauso die allgemeinen Entwicklertools mit C++ sowie die Header von e2fsprogs unterstützte Versionen 1.41.9 bis 1.41.14

Im Einzelnen wären folgende Pakete mit ihren Abhängigkeiten zu installieren : gcc ; gcc-c++ ; make ; e2fsprogs-devel

Quellcodearchiv downloaden

 wget http://sourceforge.net/projects/extundelete/files/extundelete/0.1.8/extundelete-0.1.8.tar.bz2/download

Archiv auspacken

tar -xjf extundelete-0.1.8.tar.bz2

in das Unterverzeichnis "extundelete*/src" wechseln dort make ausführen. ( bei neueren Versionen erst "./configure")

cd extundelete-0.1.8/src/
make

Das Ergebnis ist eine ausführbare Datei mit Namen extundelete im Unterverzeichnis src/
Installieren braucht man das Programm nicht unbedingt, es reicht wenn man es in ein Arbeitsverzeichnis kopiert oder man könnte es auch dort an Ort und Stelle ausführen, wo es kompiliert wurde. Dadurch kann es, wenn man es nur einmalig benötigt wird, anschließend auch schnell wieder gelöscht werden.

cp extundelete/TEMP/ARBEITS/VERZEICHNIS/
cd /TEMP/ARBEITS/VERZEICHNIS/
./extundelete --help

Hinweise und Beispiele zur Benutzung

Es wird dringend empfohlen mit einer Kopie des entsprechenden Filesystems zu arbeiten. Wo das nicht möglich ist, geht es auch mit dem Filesystem selbst, nur sollte es auf keinem Fall in dieser Zeit mit Schreibzugriff eingehängt sein. Wenn man mit einer Image-Kopie vom Filesystem arbeitet wird, benötigt man theoretisch keine Rootrechte.
Im Arbeitsverzeichnis sollte genügend freie Plattenkapazität vorhanden sein, da dorthin die wiederhergestellten Dateien geschrieben werden.

Bei extundelete werden im Gegensatz zu ext3grep keine "stage"-Dateien angelegt auf die man gegenenfalls achten muss. Abgelegt werden die Dateien ebenfalls in einem Unterverzeichnis des aktuellem Verzeichnisses mit dem Namen "RECOVERED_FILES/"
Im Gegensatz zu ext3grep werden jedoch Dateien die mehrmals restored werden, dort nicht jedes mal überschrieben, sondern bekommen zusätzlich noch eine Endung ".v1 .v2 .v3 ......" an den Dateinamen angehängt, so das man dann bei mehrere Versuchen auch mehrere Versionen ein und der selben Datei hat.

Einen Überblick über die derzeit aktuell unterstützten Optionen kann man auch hier finden.

Ein paar Beispiele:

Eine einzelne Datei wiederherstellen: es muss auch hier der komplette Pfad zur Datei wie bei ext3grep angegeben werden. (Das ist im Moment noch etwas schwierig, da die Option --dump-names noch nicht implementiert ist.)

./extundelete test.iso --restore-file dir/subdir/filename

Ein komplettes Verzeichnis recursiv wiedergewinnen. (Verzeichnis hier "testdir/" im Root des Filesystems)

./extundelete test.iso --restore-directory testdir 

Eine Dateiliste wiederherstellen. Die Liste besteht aus den Dateinamen mit Pfad. Eine Datei pro Zeile. also zB so hier

# cat filename.log
test8/datei_follow.log
test8/test5
test8/test5/.Hallo1
test8/test5/.Hallo2
test8/test5/.Hallo3
test8/test5/.Hallo4
test8/test6
test8/test6/dir1
test8/test6/dir1/dir2
test8/test6/dir1/dir2/dir3
test8/test6/dir1/dir2/dir3/dir4
test8/test6/dir1/dir2/dir3/dir4/Testdatei.txt 

Achtung: Der Befehl ist nicht zu verwechseln mit dem zum Wiederherstellen nur einer einzigen Datei

./extundelete test.iso --restore-files filename.log

Alle als gelöscht zu findenden Dateien restaurieren.

./extundelete test.iso --restore-all

Besser ist es jedoch den Löschzeitraum möglichst genau einzuschränken, damit nicht uralte Dateien mit hergestellt werden. Die Zeitangabe auch hier in Sekunden seit 1970. (Hier im Beispiel mal gleich in der Befehlszeile erledigt.) Es sollen alle Dateien die vor mindestens 16 Stunden aber höchstens vor 18 Stunden gelöscht wurden wiederhergestellt werden.

./extundelete test.iso --after $(date -d "-18 hour" +%s) --before $(date -d "-16 hour" +%s) --restore-all

Hinweise :

Allgemein gilt dasselbe wie bei ext3grep.

---

ext4magic

Mit ext4magic gibt es ein weiteres Tool, welches das Wiederherstellen von Dateien aus Journaldaten ermöglicht. Es baut auf den Erfahrungen von ext3grep und extundelete auf, und geht dabei ein paar Schritte weiter. Es ermöglicht auch die Wiederherstellung der User- und Zugriffsrechte, der Zeitstempel, unterstützt mit Ausnahme von Sockets alle Dateitypen und auch Hardlinks. Auch das Wiederherstellen von Dateiattributen ist möglich und kann optional beim compilieren aktiviert werden. Das Wiederherstellen überschriebener Dateien/Verzeichnisse oder älterer Dateiversionen ist in gewissem Maß möglich, soweit die Journaldaten dafür ausreichend sind. Unterstützt wird dabei sowohl ext3 als auch ext4.

Das Programm hat eine Vielzahl von Anzeigeoptionen und ermöglicht somit auch Untersuchungen am Filesystem. Somit können über die Nutzung der Journaldaten Manipulationen und Änderungen an Dateien und Verzeichnissen ermittelt und verfolgt werden, soweit sich die Daten dazu noch im Journal befinden. Die Vielzahl der Funktionen macht dieses Programm jedoch in der Anwendung nicht ganz einfach.

Weitere Möglichkeiten und Funktionen

ext4magic besitzt Funktionen für ein mehrstufiges Recover welches speziell für den Fall eines versehentlich rekursiven Löschens abgestimmt ist. Wird das Filesystem nach einem solchem Löschvorgang baldmöglichst umountet und nicht weiter benutzt hat man mit den neuen Magic-Funktionen (derzeit verfügbar für ext3 in Versionen 0.2.x und für ext4 in Versionen 0.3.x ) sehr gute Chancen auch Dateien wiederherstellen zu können, von denen keine alte Inodekopie mehr vorhanden sind. Ermöglicht wird das durch ein mehrstufiges Verfahren. Im ersten Schritt werden alle Dateien wiederhergestellt die aus Inodekopien im Journal gewonnen werden können. Nachfolgend wird mit einem neuen sehr speziell auf das Filesystem abgestimmten File Carving Verfahren versucht, auch die Dateien zu finden, von denen keine Inodekopie mehr vorhanden sind. Im Gegensatz zu anderen Recovertools, wie zB PhotoRec, werden in den Magic-Funktionen jedoch nicht alle Datenblöcke des Filesystems untersucht. Es werden aus den Journaldaten, welche während des Löschens geschrieben wurden, versucht die Datenblöcke gezielt zu ermitteln, die gelöscht worden sind und es werden auch alle Datenblöcke übersprungen die schon durch das Recovern der Inodekopien aus dem Journal ihre Verwendung wieder gefunden haben. Damit ist auch effektives Wiederherstellen der Daten in nur teilweise gelöschten Filesystemen möglich. Diese neuen Funktionen nutzen unter anderem auch filesystemtypische Metablöcke für das Zusammenbauen der Dateien. Solche Daten werden von den meisten Recovertools weniger bis gar nicht genutzt, da viele dieser Programme darauf abgestimmt wurden, möglichst universell auf vielen unterschiedlichen Filesystemen zu arbeiten. Im Ergebnis kann ext4magic in der derzeitigen Ausbaustufe auf ext3 auch viele fragmentiert vorhandene Dateien und damit auch sehr große Dateien wiederfinden. Viele andere typische Carving Tools haben mit solchen Dateien Probleme und können sie nicht, nur teilweise oder beschädigt wiederherstellen. Unter ext4 werden Dateien gefunden die unfragmentiert waren, und Dateien die sehr stark fragmentiert vorgelegen haben, zB sehr große Dateien, oder Dateien welche geschrieben wurden als das Filesystem so gut wie voll war. Derzeit können Dateien welche aus 2 bis 4 Fragmenten bestehen noch nicht gefunden werden, es wird noch daran gearbeitet ein Recover auch solcher Dateien für einige Dateitypen möglich zu machen.

Die Vorteile dieses Verfahrens:

1. Verknüpfung und Ergänzung beider Recoververfahren in einem einzigem Tool für das optimale Ergebnis
2. kann auch in nur teilweise gelöschten Filesystemen effizient nur nach den wirklich gelöschten Dateien suchen
3. es wird so gut es geht vermieden solche Datenbereiche auszuwerten, die mit dem letztem Löschvorgang nichts zu tun haben
4. Datenbereiche werden nicht mehrfach recovert und der Datenschrott beim Recovern wird verringert
5. z.T. werden fragmentiert abgelegte Dateien, die sonst sehr schwierig zu restaurieren sind, gefunden

ext4magic stellt im optionalen Expert-Mode auch Funktionen zur Verfügung, mit denen aus defekten oder teilweise überschriebenen Filesystemen versucht werden kann, noch Dateien zu retten (funktioniert nur bevor versucht wurde ein komplett defektes Filesystem mit fsck wieder zu reparieren).

ext4magic Links und Dokumentation

Informationen im Web dürften zur Zeit vor allem auf die alte Projektseite und das Wiki bei Berlios zeigen, und sind damit nach der endgültigen Stilllegung der Entwicklungsplattform von Berlios nicht mehr erreichbar. Die alten Inhalte der ext4magic Dokumentation aus dem Berlios-Wiki sind derzeit zwischengelagert bei Sourceforge.net zu finden deutsch englisch

Aktueller Source Download

ext4magic-0.2.4 mit der Magic-Funktion für ext3

ext4magic-0.3.2 mit der Magic-Funktion für ext4

Einige Distributionen bieten fertige Community Pakete von ext4magic-0.3.x an. zu finden zB über pkgs.org
Die ext4magic Entwicklung stellt selbst auch für einige RPM basierende Distributionen fertige Pakete online. Dort wären im Bedarfsfall auch die ext4magic-0.2.4 als Paket verfügbar

Links und Quellen

• http://www.nongnu.org/ext2-doc/ext2.html Dokumentation "The Second Extended File System"