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 Inodenummer mit dem Dateinamen verknüpft ist. In einem ext3/4 Filesystem werden die Daten in der Inode soweit gelöscht, das es schwierig wird eine versehendliche 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 verketterter 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 FilesystemCache 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. Recovern 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öringen 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 versehendlich gelöschten offene Dateien

Dateien aus dem /proc Verzeichs 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 sowas 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 entgültig im Filesystem gelöscht. Diese 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 immernoch 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, weiterschreiben. Diese Änderungen werden dann natürlich nicht mehr in unsere neu angelegte Datei registriert. Wir haben ja nur eine Momentaufname als Kopie. So kann es hier sein, das wir die letzten Änderungen an einer solchen Datei verlieren. ZB bei Datenbankdateien währe 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 einer 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 versehendlich 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 erstmal 3 Minuten lang nur den Kopf benutzen und versuchen überhaupt erstmal zu begreifen, was eventuell schief gelaufen sein könnte: wann gings 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 desshalb 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 und Rechner beruigen (zB Singleusermodus wenn man genügend Konsolerfahrung 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 durchsuchen 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 wieder recovern 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, desdo mehr Dateien werden solche Programme finden können.
7. Informationen sammeln: Parititionsgrößen, Mountpoints, Filesystemtype, 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ähre eventuell ganz unwichtig.
8. Ist das betroffene Filesystem soweit beruigt, das 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 Orignal, 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. Ließt 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 Dateientype, insbesonder bei Dateien welche Metadaten in sich bergen den Dateinamen und einige Eigenschaften wieder richtig zu setzen. Für einige Dateientypen wird eventuell noch der gefundenen Datei wieder eine richtige Dateiendung gegeben, die auf den wahrscheinlichsten Datentype 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 eigenet 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 eine Tool aus TestDisk Mit seiner Hilfe ist es möglich verlorene oder gelöschte Dateien durch Scan des Datenträgers wiederzufinden. PhotoRec unterstützt viele Dateisysteme und ist nicht mal auf ein funktionierendes Filessystem 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 Tips 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 konsitent 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 immernoch 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 können 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 das sie jedoch noch nicht anderweidig benutzt wurden, ist groß. Damit könnte jetzt problemlos eine Kopie der gelöschte Datei erzeugt werden. Programme die das können sind ext3grep ; extundelete ; ext4magic

Haben wir uns eine Datei überschrieben, zB weil wir statt mit der Umleiung ">> 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ähre es mit einigem Hintergrundwissen noch manuell möglich. Mit extundelete scheint das derzeit überhaupt nicht möglich zu sein.

---

ext3grep

Einleitung :
ext3grep ist ein Konsol Programm 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 und mit deren Hilfe gelöschten Dateien wieder hergestellt werden können.

Vorteile :
Es kann gezielt Kopien sowohl von, einzelnen gelöschte Dateien, oder auch von allem als gelöscht erkannten des Filesystems mitsamt Dateinamen mit Path und den 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 diesen Zeitraumes gelöscht wurden. Es kann eine Liste aller in Verzeichnisdatenblöcken gefundenen Dateinamen erstellt werden und 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 zusätzliche Optionen ermöglichen sehr gute und hilfreichen 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 Dateien 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 zZ 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 könnten.

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ähren 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, es geht 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 scant, 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 jedesmal gelöscht werden (damit sie bei erneuter Verwendung von ext3grep wieder neu erzeugt werden) nachdem man das Filesystem wieder Schreibend eingehängt hatte oder zB ein anders Filesystem mit dem selben Kopienamen bearbeiten will. Sonst kommt ext3grep durcheinander.

Die recoverten 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 recovern, die ab einer bestimmten Zeit gelöscht wurden

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

Eine Liste der Dateinamen erzeugen von denen ext3grep annimmt, das es sie recovern könnte

./ext3grep test.iso --dump-names

Eine einzelne ganz bestimmte Datei "Verzeichnis/Path/dateiname.txt" recovern. 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 unzureichend Ergebnisse liefern
3. Niemals, und auf gar keinen Fall versuchen, Dateien aus dem selben Filesystem wiederherzustellen, in das man gerade die recoverten 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 recovern lassen, damit nicht Unmengen uralte Dateien recovert 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 wieder recovern lassen, Ein Backup ersetzt dieses Tool also keinesfalls
8. Möglichst nicht erst viel im Filesystem weiter schreiben bevor man recovert
9. Die recoverten 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 recoverten 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 weites gehende 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. Es wird derzeit aktiv daran entwickelt. Das Wiederherstellen von Dateien ist ohne großartige Spezialkenntnisse von jedermann möglich.

kleine Mängel :
Es sind noch längst nicht alle beabsichtigten Funktionen implementiert. Noch spärliche Doku. Derzeit können nur der reine Dateiinhalt wiederhergestellt werden. Nützliche Zusatzfunktionen, analog ext3grep, sind leider derzeit noch nicht implementiert.

Fazit (des Autor dieses Wikibeitrages) :
Noch junges Projekt mit sehr guten Potential. einige Test und Wiederherstellung von Dateien und Verzeichnissen sowohl auf ext3 wie ext4 begeistern jedoch, auch wenn derzeit mehr oder weniger "nur" die reinen Dateidaten mit ihrem Namen und Path möglich sind. Die Datendateien sind das Wichtigste, das scheint prima zu funktionieren.

Installation von undelete

Bitte immer die aktuellste Version nehmen, derzeit wurde hier die Version 0.1.8 getestet. (Spätere Versionen können sich in der Installation geringfügig ändern, falls das Programm größer wird und dort dann automake- oder cmake-Tools eingesetzt werden sollten.) Es muss hier natürlich in jedem Fall noch selbst kompiliert werden, geht ähnlich (im Moment sogar noch einfacher) ext3grep.
(Einige Distributionen scheinen derzeit auch Pakete anzubieten) Benötigt werden genauso die allgemeinen Entwicklertools mit C++ sowie die Header von e2fsprogs für Unterstützung von ext4 brauchen wir natürlich die aktuelle Versionen von e2fsprogs auf dem Rechner.

im einzelnen währen 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/downl

Archiv auspacken

tar -xjf extundelete-0.1.8.tar.bz2

in das Unterverzeichnis "extundelete*/src" wechseln dort make ausführen.

cd extundelete-0.1.8/src/
make

Das Ergebnis ist eine ausführbare Datei mit Namen extundelete im Unterverzeichnis src/
Zu installieren braucht man das Programm nicht unbdingt, 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, es geht 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.

Bei extundelete werden im Gegensatz zu ext3grep keine "stage"-Dateien angelegt auf die man gegenenfalls achten muss. Abgelegt werden die Dateien ebenfalls in einem Unterverzeichs 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 restoren, es muss auch hier der komplette Path 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 komplette Verzeichnis recursiv wiedergewinnen. (Verzeichnis hier "testdir/" im Root des Filesystems)

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

Eine Dateiliste wiederherstellen. Die Liste besteht aus Dateinamen mit ihrem Path. 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 verwechsen mit dem zum restore nur einer einzigen Datei

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

Alle als gelöscht zu findende Dateien restoren.

./extundelete test.iso --restore-all

Besser ist es jedoch die Löschzeitpunkt 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 wieder restored werden.

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

Hinweise :

Allgemein gilt das selbe wie bei ext3grep.

---

ext4magic

Mit ext4magic entsteht derzeit ein weiteres Konsol Tool, welches das recovern 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. ACL ist noch vorgesehen hat aber derzeit keine Priorität in der Entwicklung. Das Wiederherstellen überschriebener Dateien/Verzeichnisse oder älterer Dateiversionen ist in gewissen Masse möglich, soweit die Journaldaten dafür ausreichend sind. Unterstützt wird dabei sowohl ext3 als auch ext4.

Derzeitig dort in Entwicklung ist ein mehrstufiges Recover welches speziell für den Fall eines "rm -rf *" abgestimmt ist. Nach dem Wiederherstellen alle Dateien die aus Inodekopien im Journal gewonnen werden können, wird an einem nachfolgenden Recover-Scan-Verfahren gearbeitet. Dieses recovert Dateien ähnlich dem gebräuchlichen Verfahren durch scannen und auswerten der Datenblöcke im Filesystem. Im Gegensatz zu anderen Recovertools, wie zB PhotoRec, werden jetzt jedoch nicht alle Datenblöcke des gesamten Filesystems untersucht. Es werden aus Kopien von Metadaten aus dem Journal, die während des Löschens geschrieben wurden, die Datenblöcke gezielt ausgesucht, 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. Diese Funktionen nutzen unter anderem auch die filesystemtypischen Metablöcke im Filesystem für das zusammenbauen der Dateien, welche von den meisten Recovertools welche möglichst universell auch defekte und viele unterschiedliche Filesysteme unterstützen möchten, meistens weniger genutzt werden. Diese Funktionen für ext4magic werden hierfür speziell auf die Eigenschaften und Besonderheiten der beiden unterstützten Filesystemtypen einzeln 100%ig eingestellt.

Die angestrebten Vorteile dieses Verfahrens:

1. Verknüfung und Ergänzung beider Recoververfahren in einem einzigem Tool für das optimalste 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. zT werden fragmentiert abgelegte Dateien, die sonst sehr schwierig zu recovern sind, gefunden

Derzeitig ist dieses Verfahren nur für ext3 verfügbar und befindet sich noch im Teststadium, die Entwicklung noch nicht abgeschlossen. Eine Entwicklung dieser Funktion auch speziell für ext4 wird sich anschließen, ist aber derzeit noch Zukunftsmusik.

Weiterreichende Informationen für Installation, Benutzung sowie Hintergrundinformationen sind über die Projektseite oder das deutsche Wiki zu finden.

Links und Quellen

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