Verlorene Dateien wiederherstellen ext3 ext4: Unterschied zwischen den Versionen

Aus Linupedia.org
Wechseln zu: Navigation, Suche
K (falsches Verzeichnis)
K (Update ext4magic Version)
 
(22 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{UnderConstruction}}  noch etwas Geduld, dauert noch ein paar Tage [[Benutzer:Robi|Robi]] 19:34, 9. Dez. 2009 (UTC)
+
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. [http://linux.die.net/man/8/debugfs debugfs]
 
 
 
 
 
 
 
 
Wird eine Datei gelöscht, dann bleiben die Datenblöcke dieser Datei von der Löschung unberüht. Die Löschung der Datei erfolgt in den Verwaltungsdaten ( [[Inode]]) der Datei sowie in den Verzeichnissen die die Inodenummer mit dem Dateinamen verknüpft. 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. [http://linux.die.net/man/8/debugfs 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.  
 
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.  
Zeile 21: Zeile 16:
 
Die Gesamtheit einer normalen Dateien bestehen im ext2/3/4 Filesystem aus mehreren Einzelkomponenten
 
Die Gesamtheit einer normalen Dateien bestehen im ext2/3/4 Filesystem aus mehreren Einzelkomponenten
 
; '''die Datenblöcken''' :
 
; '''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, desdo mehr solche Datenblöcke gehören zu dieser Datei.
+
* 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]]''' :
 
; '''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 auffindbar. Bei großen Dateien reicht die direkte Adressierungsmöglichkeiten der Inode nicht aus und es werden zwischen die Datenblöcke weitere Linkblö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 Linkblöcke unterbrochen. Große Dateien stehen also nicht in einem Stück auf der Festplatte, da Verwaltungsdaten dazwischen eingeschoben sind.
+
* 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''' :
 
; '''der Verzeichnisseintrag''' :
Zeile 30: Zeile 25:
  
 
; '''die Kette der Verzeichnisse''' :
 
; '''die Kette der Verzeichnisse''' :
* Auch die einzelnen Verzeichnisse sind in den Verzeichnissdateien mit einem Namen und der Inode der jeweils untergeordneten Verzeichnisdateien enthalten. 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.
+
* 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 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 geschreiben wurde.   
+
Ä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:<br>
 
Beim Löschen von Dateien in ext3/4 passiert nun vereinfacht folgendes:<br>
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 Inode ausgekettet (nicht gelöscht), somit sind diese Dateinamen dann im Dateisystem nicht mehr sichtbar. Es werdem also nicht alle Spuren einer Datei beim Löschen entgü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 durchgeführten Löschung einer Datei, ausgesprochen schwierig gestalt.
+
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.
  
  
Zeile 45: Zeile 40:
  
  
=== wiederherstellen von versehendlich gelöschten offene Dateien  ===
+
=== wiederherstellen von versehentlich gelöschten offene Dateien  ===
  
==== Dateien aus dem /proc Verzeichs wiedergewinnen ====
+
==== 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".  
 
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".  
  
Wenn man dieses rechtzeitig bemerkt, dann ist es ersteinmal Halb so schlimm. Solange eine Datei von einem Prozess noch geöffnet ist, existiert im Rechner noch der Verweis auf die Datei, und der entsprechende Prozess kann weiter mit dieser Datei arbeiten, auch wenn man sie im Dateisystem nicht mehr findet. Andere Prozesse können diese Datei jetzt 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 schließt, oder dieser Prozess beendet wird, dann ist diese Datei dann entgültig gelöscht. Diese kann man zum Beispiel auch bemerken, wenn man versucht, eine überlange aktuelle Logdatei zu löschen. Man hat die riesen-Datei zwar gelöscht, sieht sie auch nicht mehr mit '''"ls"''', aber der Speicherplatz dieser Datei wird einfach nicht freigegeben. Diese Logdatei ist dann noch von einem Prozess geöffnet der hier seine Logs nach wie vor in die 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.
+
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 [http://linux.die.net/man/8/lsof lsof] finden.
 
Eine solche Datei kann man mit dem Befehl [http://linux.die.net/man/8/lsof lsof] finden.
Zeile 66: Zeile 61:
 
lr-x------ 1 rob users 64  9. Dez 19:09 /proc/5139/fd/3 -> /home/rob/Dokumente/orig.txt (deleted)</pre>
 
lr-x------ 1 rob users 64  9. Dez 19:09 /proc/5139/fd/3 -> /home/rob/Dokumente/orig.txt (deleted)</pre>
  
Allerdings, können wir hier auch nicht direkt auf die schon gelöschte Datei zugreifen, aber wir können ihren Inhalt auslesen und diesen wieder als Datei schreiben. Dabei würde jetzt eine neue Datei mit gleichem Namen und gleichem Inhalt angelegt.  
+
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.  
 
<pre>rob@dhcppc0:~/Dokumente> cat /proc/5139/fd/3 > /home/rob/Dokumente/orig.txt
 
<pre>rob@dhcppc0:~/Dokumente> cat /proc/5139/fd/3 > /home/rob/Dokumente/orig.txt
 
rob@dhcppc0:~/Dokumente> ls -l /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</pre>
 
-rw-r--r-- 1 rob users 72830  9. Dez 19:24 /home/rob/Dokumente/orig.txt</pre>
  
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 unserer neu angelegten Datei gemacht. So kann es hier sein, das wir die letzten Änderungen an der Datei verlieren. ZB bei  Datenbankdateien währe sowas dann allerdings fatal. Hier könnte zB [http://linux.die.net/man/1/tail tail] helfen, um die Datei mit allen Änderungen vollständig wieder herzustellen. Siehe auch [http://www.jfranken.de/homepages/johannes/vortraege/lsof_inhalt.de.html#ToC6 Beispiele]
+
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 [http://linux.die.net/man/1/tail tail] helfen, um die Datei mit allen Änderungen vollständig wieder herzustellen. Siehe auch [http://www.jfranken.de/homepages/johannes/vortraege/lsof_inhalt.de.html#ToC6 Beispiele]
  
  
  
 
-----
 
-----
 +
  
  
Zeile 81: Zeile 77:
 
=== Ich habe gerade all meine Daten gelöscht,  Erste Hilfe ===
 
=== Ich habe gerade all meine Daten gelöscht,  Erste Hilfe ===
  
Hier fehlt noch was  
+
<!-- Der ganze Abschnitt gefällt mir noch nicht so richtig , nach mehreren Versuchen bleibt er aber jetzt trotzdem erst mal so stehen ~~~~ -->
 +
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. ;-) <br>
 +
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 Journal<!--ing -->filesystem. 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.
 +
# 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.
 +
 
 +
 
  
 
-----
 
-----
Zeile 87: Zeile 100:
  
  
=== Dateien anhand ihres Types mit einem Flächenscan aus den Datenblöcken wieder gewinnen ===
+
=== 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 dir einzelnen Blöcke insbesondere den Blockanfang an, wird man dort an bestimmten Eigenschaften den Begin 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 der 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 zusammenzubauen. Wenn das ein einigermaßen intelligentes Tool macht, und dieses auch noch ein bischen Ahung hat, um welches Filesystem es sich handeln könnte, dann hat man sogar die Chance auch Dateien aus Blöcken wiederzufinden und zusammenzubauen die auf der Platte fragmentiert vorliegen. Tools die so nach verlorenen Dateien suchen gibt es eine ganze Menge.
+
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 die 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. Solche Tools sind eventuell noch in der Lage der Datei eine Dateiendung zu geben, die auf den wahrscheinlichsten Datentype hinweist, aber sie sind nicht in der Lage den gefundenen Dateien ihre ursprünglichen Namen wieder zugeben, geschweige denn zu entscheiden welchem User diese Datei eigentlich zuzuordnen währe. 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.
+
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.
  
  
Zeile 98: Zeile 111:
 
==== PhotoRec ====
 
==== PhotoRec ====
  
[http://www.cgsecurity.org/wiki/PhotoRec_DE PhotoRec] ist eine Tool aus [http://www.cgsecurity.org/wiki/TestDisk_DE TestDisk]  
+
[http://www.cgsecurity.org/wiki/PhotoRec_DE PhotoRec] ist ein Tool aus [http://www.cgsecurity.org/wiki/TestDisk_DE 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 formatiert wurde.
+
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 [http://www.cgsecurity.org/wiki/Wiederherstellbare_Dateiformate_unter_PhotoRec Dateitypen], die es wieder herstellen kann.
 
Es kennt eine ganze Reihe von [http://www.cgsecurity.org/wiki/Wiederherstellbare_Dateiformate_unter_PhotoRec Dateitypen], die es wieder herstellen kann.
  
Testdisk sollte man in verschiedenen Distributionen und auf verschiedenen Hilfs CD/DVDs finden. Unter OpenSuse sollten fertige [http://packages.opensuse-community.org/index.jsp?searchTerm=testdisk&distro=openSUSE_111 Pakete bei Packman] zu finden sein.   
+
Testdisk sollte man in verschiedenen Distributionen und auf verschiedenen Hilfs- CD/DVDs finden. Unter OpenSuse sollten fertige [http://packages.opensuse-community.org/index.jsp?searchTerm=testdisk&distro=openSUSE_111 Pakete bei Packman] zu finden sein.   
  
 
Die Benutzung von PhotoRec ist in diesem [http://www.cgsecurity.org/wiki/PhotoRec_Schritt_f%C3%BCr_Schritt HOWTO] wohl gut genug beschrieben, so das wir das hier gar nicht erst versuchen müssten.
 
Die Benutzung von PhotoRec ist in diesem [http://www.cgsecurity.org/wiki/PhotoRec_Schritt_f%C3%BCr_Schritt 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. [http://www.cgsecurity.org/wiki/Nach_dem_Gebrauch_von_PhotoRec Hier] und an vielen anderen Stellen wirst du sicherlich Tips und Tricks dazu finden.  
+
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. [http://www.cgsecurity.org/wiki/Nach_dem_Gebrauch_von_PhotoRec Hier] und an vielen anderen Stellen i, Netz wird man sicherlich Tipps und Tricks dazu finden.  
 +
 
  
  
  
 
-----
 
-----
 
 
  
  
Zeile 118: Zeile 130:
 
=== Die Dateien mit Hilfe alter Filesystem-Journaldaten wieder herstellen ===
 
=== 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. Das sichert auch bei einem Rechnerabsturz die Konsistens des Filesystems und ermöglicht einen schnelle Wiederherstellung eines konsitenten Filesystems nach einem Absturz. In diesem Fall müssen nur die noch offenen Änderungen im Journal abgearbeitet werden.
+
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.<br>
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 Inode. Und diese stehen dort oftmals einen längern Zeitraum und da immer ganze InodeBlöcke dort abgelegt sind, ist die Wahrscheinlichkeit sehr groß das man von vielen Dateien dort eine alte Inode findet.  
+
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 herstellen zu können. 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 mit der ehemaligen Inodenummer noch in den Datenblöcken der Verzeichnisdateien. dort müsste der ehemalige Dateiname gesucht werden, um die ehemalige Inode zu ermitteln. Von dieser Inode benötigen wir jetzt die älteste Kopie die keinen Löschzeitstempel hat, um aus ihr die Links zu den Datenblöcken, die Größe und alle anderen Eigenschaften der gelöschten Datei zu erfahren. Die Datenblöcke auf die diese Inodekopie verweist, sind zwar 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''' und '''extundelete'''. (siehe beide weiter unten)
+
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 Umleiung "''>> Dateiname''" (die soviel bedeutet wie, Ausgabe am Ende der Datei Dateiname weiterschreiben) 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. Eine automatische Funktion dafür gibt es in den beiden hier genannten Programmen derzeit nicht. Mit '''ext3grep''' ist es mit einigem Hintergrundwissen manuell möglich. In '''extundelete''' ist eine solche Funktion, die alle verfügbaren alten Dateiversionen einer Datei wiedergewinnen kann, in Zukunft beabsichtigt, aber noch nicht realisiert.     
+
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.     
  
 
      
 
      
  
 +
-----
  
-----
 
  
  
Zeile 135: Zeile 147:
  
 
'''Einleitung''' : <br>
 
'''Einleitung''' : <br>
'''[http://groups.google.com/group/ext3grep/web/ext3grep-source-code-and-overview ext3grep]''' ist ein Konsol Programm von Carlo Wood. Es wurde wohl aus der Not heraus entwickelt und die allgemeine Vorgehensweise und das Prinzip sind in seinem [http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html Howto] sehr schön beschrieben. Carlo Wood hatte die revolutionäre Idee aus dem Filesystem-Journal Backups von früheren Inodeblöcken zu gewinnen und mit deren Hilfe die Datenblöcke der gelöschten Dateien wieder zu finden.  
+
'''[http://groups.google.com/group/ext3grep/web/ext3grep-source-code-and-overview 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 [http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html 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''' : <br>
 
'''Vorteile''' : <br>
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 orginal Zugriffsrechten und Zeitstempel wieder hergestellt werden. Man kann dabei den Löschzeitraum zeitlich eingrenzen, so das man gezielt nur versucht die 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 ist auch einer Art Löschstatistik, die die Anzahl der Löschvorgänge im zeitlichen Zusammenhang anzeigt. 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. Jedoch einfaches normales Wiederherstellen von erst kürzlich gelöschten Dateien ist damit ohne spezielle Kenntnisse mit nur wenigen Optionen wohl für die meisten Linuxuser fast problemlos auf der Konsole machbar.       
+
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''' : <br>
 
'''kleine Mängel''' : <br>
Das Programm arbeitet relativ langsam, da es einmalig aufwendige Scans nach allen Dateinamen über das gesamte Dateisysten 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 und in Logdateien abgelegt werden.  
+
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. 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 sehr schwer einen Einstieg für eine Weiterentwicklung finden könnten.
+
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 [http://de.wikipedia.org/wiki/Byte-Reihenfolge 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) :<br>
 
'''Fazit''' (des Autor dieses Wikibeitrages) :<br>
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 Wiederhestellen bei extremen Problemfällen zu gewinnen.  
+
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.  
  
  
Zeile 157: Zeile 169:
 
Benötigt werden die allgemeinen Entwicklertools mit '''C++''' sowie die Header von  '''e2fsprogs'''
 
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'''  
+
Im einzelnen wären folgende Pakete mit ihren Abhängigkeiten zu installieren : '''gcc ; gcc-c++ ; make ; e2fsprogs-devel'''  
  
 
Quellcodearchiv downloaden
 
Quellcodearchiv downloaden
Zeile 165: Zeile 177:
 
  tar -xzf ext3grep-0.10.1.tar.gz
 
  tar -xzf ext3grep-0.10.1.tar.gz
  
in das Verzeichnis wechseln dort '''configure''' und '''make''' ausführen.
+
in das Verzeichnis wechseln, dort '''configure''' und '''make''' ausführen.
 
  cd ext3grep-0.10.1/
 
  cd ext3grep-0.10.1/
 
  ./configure
 
  ./configure
 
  make
 
  make
Das Ergebnis ist eine Ausführbare Datei namens '''ext3grep''' im Unterverzeichnis '''src/''' <br>
+
Das Ergebnis ist eine ausführbare Datei namens '''ext3grep''' im Unterverzeichnis '''src/''' <br>
Zu installieren braucht man das Programm nicht unbdingt, es reicht wenn man es in das 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, dann auch anschließend schnell wieder gelöscht werden.  
+
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/
 
  cp src/ext3grep /TEMP/ARBEITS/VERZEICHNIS/
 
  cd /TEMP/ARBEITS/VERZEICHNIS/
 
  cd /TEMP/ARBEITS/VERZEICHNIS/
Zeile 179: Zeile 191:
 
===== Hinweise und Beispiele zur Benutzung =====
 
===== 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. <br>
+
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. <br>
 
Im Arbeitsverzeichnis sollte genügend freie Plattenkapazität vorhanden sein, da dorthin die wiederhergestellten Dateien geschrieben werden.
 
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'''<br>
+
Wenn ext3grep das Filesystem scannt, legt es im aktuellem Verzeichnis 2 Dateien an. '''FILESYSTEMNAME.ext3grep.stage1 '''und''' FILESYSTEMNAME.ext3grep.stage2'''<br>
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 Imagekopienamen bearbeiten will. Sonst kommt ext3grep durcheinander.
+
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 recoverten Dateien landen in einem Unter-Verzeichnis  '''"RESTORED_FILES/"''' das ext3grep selbst anlegt.
+
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 [http://linux.die.net/man/1/date Manpage von date] nachlesen.
 
Es werden für einige Optionen Zeitangaben im Sekundenformat seit 1970 benötigt. Diese kann man zB wie folgt ermitteln, oder in der [http://linux.die.net/man/1/date Manpage von date] nachlesen.
 
  date +%s                            #jetzt
 
  date +%s                            #jetzt
Zeile 195: Zeile 207:
 
  ./ext3grep --help
 
  ./ext3grep --help
  
Test auf prinzipelle Unterstützung des Filesystems, auslesen des Filesystem Superblocks, ('''test.iso''' ist hier ein Filesystemimage)
+
Test auf prinzipielle Unterstützung des Filesystems, auslesen des Filesystem Superblocks, ('''test.iso''' ist hier ein Filesystemimage)
 
  ./ext3grep test.iso
 
  ./ext3grep test.iso
  
Ein Histogramm erzeugen um Herauszufinden, wann wieviele Dateien gelöscht wurden, Damit lässt sich der interessante Zeitbereich sehr genau festlegen (Zeitoptionen wie oben beschrieben)
+
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
 
  ./ext3grep --histogram=dtime --after=1202351086 --before=1202351129
  
Alle Dateien recovern die ab einer bestimmten Zeit gelöscht wurden
+
Alle Dateien wiederherstellen, die ab einer bestimmten Zeit gelöscht wurden
 
  ./ext3grep test.iso --restore-all --after=1260399600  
 
  ./ext3grep test.iso --restore-all --after=1260399600  
  
Eine Liste der Dateinamen erzeugen von denen ext3grep annimmt das es sie recovern könnte
+
Eine Liste der Dateinamen erzeugen von denen ext3grep annimmt, sie wiederherstellen zu können
 
  ./ext3grep test.iso --dump-names
 
  ./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.  
+
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
 
  ./ext3grep test.iso --restore-file Verzeichnis/Path/dateiname.txt
  
Zeile 213: Zeile 225:
 
'''Hinweise:'''
 
'''Hinweise:'''
 
# '''Das Programm ist und bleibt "Beta"'''
 
# '''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
+
# 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
# Niemals, und auf gar keinen Fall versuchen, Dateien aus dem selben Filesystem wiederherzustellen in das man gerade die recoverten Dateien wieder hinein schreibt :-)
+
# Niemals, und auf gar keinen Fall versuchen, Dateien aus dem selben Filesystem wiederherzustellen, in das man gerade die wiederhergestellten 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
+
# 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.
+
# Möglichst den Zeitraum einschränken oder genaue Dateinamen angeben, damit nicht Unmengen uralte Dateien wiederhergestellt werden.
# Es wird mit diesen hier vorgestellten einfachen Optionen besonders bei Dateien die sich sehr oft geändert haben nicht immer gelingen genau die Dateiversion zu erwischen die man gerne hätte.  
+
# 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 recovern lassen, Ein Backup ersetzt dieses Tool also keinesfalls  
+
# Nicht wirklich jede Datei wird sich jederzeit auch so wiederherstellen lassen, Ein Backup ersetzt dieses Tool also keinesfalls  
# bei '''--restore-all''' wird wahrscheinlich die Option '''--before''' nicht unterstützt
+
# Möglichst nicht erst viel im Filesystem weiter schreiben
# Möglichst nicht erst viel im Filesystem weiterschreiben eh man recovert
+
# Die wiederhergestellten Dateien sollten gründlich kontrolliert werden, auf Vollständigkeit und ordnungsgemäßen Inhalt
# 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 wiederhergestellten Dateien resultieren.
# Es wird nicht immer möglich sein, wirklich jede Datei zu recovern
+
# Gerätedateien Pipes u.ä. werden nicht unterstützt
# je nach Füllstand und Durchsatz können einzelne Datei Bestandteile 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 werden nicht unterstützt
 
 
# Eventuell werden ehemalige Hardlinks jetzt zu selbständigen Dateien (Auch den Hinweis über die Hardlinks im [http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html Howto] lesen.)
 
# Eventuell werden ehemalige Hardlinks jetzt zu selbständigen Dateien (Auch den Hinweis über die Hardlinks im [http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html Howto] lesen.)
  
Zeile 236: Zeile 246:
  
 
'''Einleitung''': <br>
 
'''Einleitung''': <br>
[http://extundelete.sourceforge.net/ extundelete] ist eine konsequente Neuentwicklung der Idee von ext3grep. Im Unterschied zu '''ext3grep''' greift '''extundelete''' konsequent auf die Funktionen des [http://e2fsprogs.sourceforge.net/ ext2fs library] zu. Dadurch können recht schnell auch aus großen Filesystemem einzelne Dateien wiederhergestellt werden.  
+
[http://extundelete.sourceforge.net/ extundelete] ist eine Überarbeitung der Idee von ext3grep. Im Unterschied zu '''ext3grep''' benutzt '''extundelete''' die Funktionen des [http://e2fsprogs.sourceforge.net/ ext2fs library] zu. Dadurch können recht schnell auch aus großen Filesystemen einzelne Dateien wiederhergestellt werden.  
  
  
  
 
'''Vorteile''' : <br>
 
'''Vorteile''' : <br>
Sehr brauchbare Laufzeiten auch in großen Filesystemen. Flexibel sowohl auf ext3 wie ext4. Analoge Funktionen und ebenfalls weitesgehend analoge Befehls-Optionen zu ext3grep. Durch die Benutzung der Libraryfunktionen erhält es automatisch die notwendige Flexibilität für eine sehr gute Unterstützung des ext3/4 Filesystems. 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.
+
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''' : <br>         
 
'''kleine Mängel''' : <br>         
Das gesammte Projekt ist noch sehr jung (wenige Monate), dadurch sind noch längst nicht alle Funktionen implementiert. Noch keine brauchbare Doku. Derzeit können nur der reine Dateiinhalt wiederhergestellt werden. Die ganzen Besitz und Dateirechte gehen noch verloren. Leere Dateien und leere Verzeichnisse scheint es noch nicht zu unterstützen, auch Hard- und Symlinks sind noch nicht möglich bzw werden als die zu verlinkende Datei restored.  Nützliche Zusatzfunktionen, analog ext3grep, sind leider derzeit noch nicht implementiert. Die Projektseite ist wohl auch noch nicht richtig so in Schwung gekommen, ein Zugriff auf den "Version Control for Source Code" bracht bisher auch nur ein leeres Verzeichnis.  
+
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) :<br>
 
'''Fazit''' (des Autor dieses Wikibeitrages) :<br>
Noch sehr 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, und ein ganzes Rootfilesystem nach dem Löschen wieder vollständig lauffähig zu restoren ist nicht die Messlatte für ein solches Tool. ;-)   
+
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.  
  
  
Zeile 258: Zeile 269:
 
===== Installation von undelete =====
 
===== 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.<br>
+
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 <br>  
Benötigt werden genauso die allgemeinen Entwicklertools mit '''C++''' sowie die Header von '''e2fsprogs''' für Unterstützung von ext4 brauchen wir natürlich aktuelle Versionen von e2fsprogs auf dem Rechner.
+
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'''  
+
Im Einzelnen wären folgende Pakete mit ihren Abhängigkeiten zu installieren : '''gcc ; gcc-c++ ; make ; e2fsprogs-devel'''  
  
 
Quellcodearchiv downloaden
 
Quellcodearchiv downloaden
   wget http://sourceforge.net/projects/extundelete/files/extundelete/0.1.8/extundelete-0.1.8.tar.bz2/downl
+
   wget http://sourceforge.net/projects/extundelete/files/extundelete/0.1.8/extundelete-0.1.8.tar.bz2/download
  
 
Archiv auspacken
 
Archiv auspacken
 
  tar -xjf extundelete-0.1.8.tar.bz2
 
  tar -xjf extundelete-0.1.8.tar.bz2
  
in das Unterverzeichnis "extundelete*/src" wechseln dort '''make''' ausführen.  
+
in das Unterverzeichnis "extundelete*/src" wechseln dort '''make''' ausführen. ( bei neueren Versionen erst "./configure")
 
  cd extundelete-0.1.8/src/
 
  cd extundelete-0.1.8/src/
 
  make
 
  make
  
Das Ergebnis ist eine Ausführbare Datei namens '''extundelete''' im Unterverzeichnis '''src/'''  <br>
+
Das Ergebnis ist eine ausführbare Datei mit Namen '''extundelete''' im Unterverzeichnis '''src/'''  <br>
Zu installieren braucht man das Programm nicht unbdingt, es reicht wenn man es in das 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, dann auch anschließend schnell wieder gelöscht werden.  
+
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/
 
  cp extundelete/TEMP/ARBEITS/VERZEICHNIS/
 
  cd /TEMP/ARBEITS/VERZEICHNIS/
 
  cd /TEMP/ARBEITS/VERZEICHNIS/
Zeile 282: Zeile 293:
  
  
 +
===== 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. <br>
==== 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. <br>
 
 
Im Arbeitsverzeichnis sollte genügend freie Plattenkapazität vorhanden sein, da dorthin die wiederhergestellten Dateien geschrieben werden.
 
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/"''' <br>
+
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/"''' <br>
 
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.
 
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.
  
Zeile 299: Zeile 308:
 
'''Ein paar Beispiele:'''
 
'''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.)''
+
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
 
  ./extundelete test.iso --restore-file dir/subdir/filename
  
Ein komplette Verzeichnis recursiv wiedergewinnen. (Verzeichnis hier "testdir/" im Root des Filesystems)
+
Ein komplettes Verzeichnis recursiv wiedergewinnen. (Verzeichnis hier "testdir/" im Root des Filesystems)
 
  ./extundelete test.iso --restore-directory testdir  
 
  ./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
+
Eine Dateiliste wiederherstellen. Die Liste besteht aus den Dateinamen mit Pfad. Eine Datei pro Zeile. also zB so hier
 
<pre># cat filename.log
 
<pre># cat filename.log
 
test8/datei_follow.log
 
test8/datei_follow.log
Zeile 319: Zeile 328:
 
test8/test6/dir1/dir2/dir3/dir4
 
test8/test6/dir1/dir2/dir3/dir4
 
test8/test6/dir1/dir2/dir3/dir4/Testdatei.txt </pre>
 
test8/test6/dir1/dir2/dir3/dir4/Testdatei.txt </pre>
Achtung: Der Befehl ist nicht zu verwechsen mit dem zum restore nur einer einzigen Datei
+
Achtung: Der Befehl ist nicht zu verwechseln mit dem zum Wiederherstellen nur einer einzigen Datei
 
  ./extundelete test.iso --restore-files filename.log
 
  ./extundelete test.iso --restore-files filename.log
  
Alle als gelöscht zu findende Dateien restoren.  
+
Alle als gelöscht zu findenden Dateien restaurieren.  
 
  ./extundelete test.iso --restore-all
 
  ./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.  
+
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
 
  ./extundelete test.iso --after $(date -d "-18 hour" +%s) --before $(date -d "-16 hour" +%s) --restore-all
  
Zeile 333: Zeile 342:
 
'''Hinweise :'''
 
'''Hinweise :'''
  
Für spezielle Hinweise ist es noch ein bischen früh. Werden wir hier nachholen wenn das Tool noch etwas weiter entwickelt wurde.  Allgemein gilt ersteinmal das selbe wie bei ext3grep.
+
Allgemein gilt dasselbe wie bei ext3grep.
 +
 
 +
 
 +
 
 +
-----
 +
 
 +
 
 +
 
 +
 
 +
====ext4magic====
 +
 
 +
Mit [http://sourceforge.net/projects/ext4magic 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 [http://www.forensicswiki.org/wiki/File_Carving 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:'''
 +
# 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
 +
# 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 [http://www.pro-linux.de/news/1/20738/berlios-entwicklungsplattform-schliesst-ihre-tore.html 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 [http://ext4magic.sourceforge.net/ext4magic_de.html deutsch] [http://ext4magic.sourceforge.net/ext4magic_en.html englisch]
 +
 
 +
 +
Aktueller Source Download
 +
:[http://sourceforge.net/projects/ext4magic/files/ext4magic-0.2.4.tar.gz/download ext4magic-0.2.4]  mit der Magic-Funktion für ext3<br>
 +
:[http://sourceforge.net/projects/ext4magic/files/ext4magic-0.3.2.tar.gz/download ext4magic-0.3.2]  mit der Magic-Funktion für ext4<br>
 +
 
 +
Einige Distributionen bieten fertige Community Pakete von ext4magic-0.3.x an. zu finden zB über [http://pkgs.org/search/?keyword=ext4magic pkgs.org]<br>
 +
Die ext4magic Entwicklung stellt selbst auch für einige RPM basierende Distributionen [http://download.opensuse.org/repositories/home:/robi-1/ fertige Pakete online]. Dort wären im Bedarfsfall auch die ext4magic-0.2.4 als Paket verfügbar
  
 
=== Links und Quellen ===
 
=== Links und Quellen ===
  
# http://www.nongnu.org/ext2-doc/ext2.html Dokumentation "The Second Extended File System"  
+
* http://www.nongnu.org/ext2-doc/ext2.html Dokumentation "The Second Extended File System"  
  
 
[[Category:Partitionen]]
 
[[Category:Partitionen]]

Aktuelle Version vom 13. September 2014, 17:37 Uhr

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