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.
Inhaltsverzeichnis
- 1 Gelöschte Dateien auf einem ext3 oder ext4 Filesystem wiederherstellen
- 1.1 Ein paar Einleitende Hintergrundinformationen
- 1.2 wiederherstellen von versehentlich gelöschten offene Dateien
- 1.3 Ich habe gerade all meine Daten gelöscht, Erste Hilfe
- 1.4 Dateien anhand ihres Type mit einem Flächenscan aus den Datenblöcken wieder gewinnen
- 1.5 Die Dateien mit Hilfe alter Filesystem-Journaldaten wieder herstellen
- 1.6 Links und Quellen
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. 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ö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.
- zuerst möglichst keine vorschnellen unüberlegten Aktionen starten. Nicht ausschalten, nicht Platte ziehen, keine größeren Programme, Scripte oder Befehle nach starten
- 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.
- 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.
- 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?
- 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.
- 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 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, desto mehr Dateien werden solche Programme finden können.
- 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.
- 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.
- 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 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 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 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:
- Das Programm ist und bleibt "Beta"
- 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
- Niemals, und auf gar keinen Fall versuchen, Dateien aus dem selben Filesystem wiederherzustellen, in das man gerade die recoverten Dateien wieder hinein schreibt :-)
- 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
- Möglichst den Zeitraum einschränken oder genaue Dateinamen recovern lassen, damit nicht Unmengen uralte Dateien recovert werden.
- Es wird mit diesen hier vorgestellten einfachen Optionen der Stand vor dem letztem Löschvorgang einer Datei hergestellt.
- Nicht wirklich jede Datei wird sich jederzeit auch so wieder recovern lassen, Ein Backup ersetzt dieses Tool also keinesfalls
- Möglichst nicht erst viel im Filesystem weiter schreiben bevor man recovert
- Die recoverten Dateien sollten gründlich kontrolliert werden, auf Vollständigkeit und ordnungsgemäßen Inhalt
- 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.
- Gerätedateien Pipes uä werden nicht unterstützt
- 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 weitest 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.
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 können nur der reine Dateiinhalt wiederhergestellt werden. Nützliche Zusatzfunktionen, analog 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 Test und Wiederherstellung von Dateien und Verzeichnissen sowohl auf ext3 wie ext4 begeistern jedoch, auch wenn 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. Leider bleiben Fragen zu Problemen selbst in den offiziellen Mailinglisten oftmals unbeantwortet.
Installation von undelete
Soweit 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ä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. ( 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/
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 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 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 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 verwechseln 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. 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.
Das Programm hat eine Vielzahl von Anzeige Optionen 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
In Entwicklung dort ist ein mehrstufiges Recover welches speziell für den Fall eines versehentlich rekursivem 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 dem 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 filesystemtypischen 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 viele unterschiedlichen Filesysteme 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:
- Verknüpfung und Ergänzung beider Recoververfahren in einem einzigem Tool für das optimale Ergebnis
- kann auch in nur teilweise gelöschten Filesystemen effizient nur nach den wirklich gelöschten Dateien suchen
- es wird so gut es geht vermieden solche Datenbereiche auszuwerten, die mit dem letztem Löschvorgang nichts zu tun haben
- Datenbereiche werden nicht mehrfach recovert und der Datenschrott beim Recovern wird verringert
- zT werden fragmentiert abgelegte Dateien, die sonst sehr schwierig zu recovern sind, gefunden
ext4magic stellt im optionalen Expert-Mode auch Funktionen zur Verfügung, mit denen aus defekten oder teilweise überschriebenen Filesysteme versucht werden kann, noch Dateien zu retten (funktioniert aber nur bevor versucht wurde ein komplett defektes Filesystem mit fsck wieder zu reparieren).
ext4magic Links und Dokumentation
Informationen für das compilieren aus dem Quellcode, Benutzung sowie Hintergrundinformationen sind über die Projektseite oder das Wiki zu finden.
Einige ausführliche Howtos für typische Anwendungsfälle sind im englischem Wiki zu finden.
Aktueller Source Download
- ext4magic-0.2.4 mit der Magic-Funktion für ext3
- ext4magic-0.3.0 mit der Magic-Funktion für ext4
Einige Distributionen bieten fertige Community Pakete an. zu finden zB über. pkgs.org
Die ext4magic Entwicklung stellt selbst auch für einige RPM basierende Distributionen fertige Pakete online. Sieht auch Installationshinweise im Wiki
Neuigkeiten: Ein Front-End für ext4magic speziell für kleine Rescue Systeme steht derzeit für die ersten Usertests zur Verfügung.
Links und Quellen
- http://www.nongnu.org/ext2-doc/ext2.html Dokumentation "The Second Extended File System"
