Verlorene Dateien wiederherstellen ext3 ext4

Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

 noch etwas Geduld, dauert noch ein paar Tage Robi 19:34, 9. Dez. 2009 (UTC)

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. 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, desdo 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 heißt ü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 sind also 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.

der Verzeichnisseintrag 

• das ist ein Eintrag in einer Verzeichnisdatei. In diesen Verzeichnissdateien wird eine Zuordnung von genau einem Dateinamen mit genau einer Inode gemacht. Hier bekommt also 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 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 gebildet.

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 Inode ausgekettet (nicht gelöscht), somit sind diese Dateinamen dann im Dateisystem nicht mehr sichtbar. Es werdem also nicht alle Spuren entgültig vernichtet, aber die Entfernung der Verlinkung zu den Datenblöcken der Datei macht ein Wiederherstellen der Datei ausgesprochen schwierig.

wiederherstellen von versehendlich gelöschten offene Dateien

Dateien aus dem /proc Verzeichs wiedergewinnen

Gelegentlich kann es vorkommen, und man löscht eine Datei versehentlich und merkt sofort: "Hilfe diese Datei wird benötigt und habe ich 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.

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 auslesen und diesen wieder als Datei schreiben. Dabei würde jetzt eine neue Datei mit gleichem Namen und gleichem Inhalt angelegt.

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

Das ganze funktioniert auf diese Weise solange wir es mit "nur zum Lesen geöffnet" Dateien haben. Ist diese Datei zum Schreiben geöffnet, können wir so auch jederzeit eine Momentaufnahme dieser Datei erzeugen. Doch danach wird der Prozess eventuell weiterhin in die alte, schon gelöschte Datei, weiterschreiben. Diese Änderungen werden dann natürlich nicht mehr in 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 tail helfen, um die Datei mit allen Änderungen vollständig wieder herzustellen. Siehe auch Beispiele

---

---

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. 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. Nach Änderungen, wie zB dem Verändern von Dateien, dem Anlegen oder Löschen werden die entsprechenden Indode Blöcke dort im Journal zur Sicherheit abgelegt. Hier sind also genau die Informationen die uns 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. Die gelöschten Dateinamen stehen mit der ehemaligen Inodenummer noch in den Datenblöcken der Verzeichnisdateien und die ehemaligen Datenblöcke sind zwar als "frei verfügbar" markiert, die Wahrscheinlichkeit das sie jedoch noch nicht anderweidig benutzt wurden, ist groß.

---

ext3grep

Einleitung :
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 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.

Vorteile :
Es kann gezielt Kopien sowohl von, einzelnen gelöschte Dateien, oder auch von allem als gelöscht erkannten des Filesystems mitsamt Dateinamen mit Path und 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.

kleine Mängel :
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. 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.

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 Wiederhestellen bei extremen Problemfällen zu gewinnen.

Installation von ext3grep

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

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

Quellcodearchiv downloaden

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

Archiv auspacken

tar -xzf ext3grep-0.10.1.tar.gz

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

cd ext3grep-0.10.1/
./configure
make

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

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

Hinweise und Beispiele zur Benutzung

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

Wenn ext3grep das Filesystem scant legt es im aktuellem Verzeichnis 2 Dateien an. FILESYSTEMNAME.ext3grep.stage1 und FILESYSTEMNAME.ext3grep.stage2 Diese Dateien nicht per Hand manipulieren, auch wenn das noch so verlockend ist. Diese Dateien müssen jedesmal gelöscht werden (damit sie neu erzeugt werden würden) nachdem man das Filesystem wieder Schreibend eingehängt hatte. Sonst kommt ext3grep durcheinander.

Die recoverten Dateien landen in einem Unter-Verzeichnis "RESTORED_FILES/" das ext3grep selbst anlegt. Es werden eventuell 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 Unterstützung des Filesystems, auslesen des Filesystem Superblocks, (test.iso ist hier ein Filesystemimage)

./ext3grep test.iso

Ein Histogramm erzeugen um Herauszufinden wann wieviele Dateien gelöscht wurden, Damit lässt sich der interessante Zeitbereich festlegen (Zeit wie oben beschrieben)

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

Alle Dateien recovern die ab einer bestimmten Zeit gelöscht wurden

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

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

./ext3grep test.iso --dump-names

Eine einzelne ganz bestimmte Datei "Verzeichnis/Path/dateiname.txt" recovern. Der Path zur Datei beginnt mit dem Wurzelverzeichnis aus der Sicht dieses Filesystems und darf nicht mit "/" beginnen. Der Dateiname muss in der oben erzeugten Liste vorhanden sein. ./ext3grep test.iso --restore-file Verzeichnis/Path/dateiname.txt

Hinweise:

1. Das Programm ist und bleibt "Beta"
2. Es geht hier nur ext3, wenn ein ext3 Filesystem mit ext4 beschrieben wurde, oder nach ext3 konvertiert wurde, wird es nicht funktionieren oder nur unzureichend Ergebnisse liefern
3. Niemals, und auf gar keinen Fall versuchen, Dateien aus dem selben Filesystem wiederherzustellen in das man gerade die recoverten Dateien wieder hinein schreibt :-)
4. Wann immer möglich keinen Filesystemcheck nach dem Löschen und vor dem Recoverversuch durchführen, besonders keinen wo man Fragen beantworten soll. Wenn der Rechner vor dem Recoverversuch noch rebootet oder ausgeschalten werden muss und man keine Kopie hat, prüfen ob man den Eintrag in der /etc/fstab auf readonly umändern kann und im sechtem Feld mit einer "0" den Filesystemcheck verhindern kann
5. Möglichst den Zeitraum einschränken oder genaue Dateinamen recovern lassen, damit nicht Unmengen uralte Dateien recovert werden.
6. Es wird mit diesen hier vorgestellten einfachen Optionen besonders bei Dateien die sich sehr oft geändert haben nicht immer gelingen genau die Dateiversion zu erwischen die man gerne hätte.
7. Nicht wirklich jede Datei wird sich jederzeit recovern lassen, Ein Backup ersetzt dieses Tool also keinesfalls
8. bei --restore-all wird wahrscheinlich die Option --before nicht unterstützt
9. Möglichst nicht erst viel im Filesystem weiterschreiben eh man recovert
10. Die recoverten Dateien sollten gründlich kontrolliert werden, auf Vollständigkeit und ordnungsgemäßen Inhalt
11. Es wird nicht immer möglich sein wirklich jede Datei zu recovern
12. je nach Füllstand und Durchsatz können einzelne Dateien schon ganz oder Teilweise zerstört sein. oder der Recover falsche Dateien liefern.
13. Gerätedateien Pipes uä werden nicht unterstützt
14. Eventuell werden ehemalige Hardlinks jetzt zu einzelnen Dateien (Auch den Hinweis über die Hardlinks im Howto lesen.)

---

extundelete

Einleitung:
extundelete ist eine konsequente Neuentwicklung der Idee von ext3grep. Im Unterschied zu ext3grep greift extundelete konsequent auf die Funktionen des ext2fs library zu. Dadurch wird können recht schnell auch aus großen Filesystemem einzelne Dateien wiederhergestellt werden.

Vorteile :
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 wiederhergestellt werden. Es wird derzeit aktiv daran entwickelt. Das Widerherstellen von Dateien ist ohne großartige Spezialkenntnisse von jedermann möglich.

kleine Mängel :
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. Leere Dateien und leere Verzeichnisse scheint es noch nicht zu unterstützen, auch Symlinks sind noch nicht möglich. Nützliche Zusatzfunktionen, analog ext3grep, sind 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.

Fazit (des Autor dieses Wikibeitrages) :
Noch sehr junges Projekt mit sehr guten Potential. einige Test Wiederherstellung von Dateien und Verzeichnissen sowohl auf ext3 wie ext4 begeistern. Auch wenn derzeit noch keine Symlinks und noch keine Zugriffrechte und Zeitstempel wiederhergestellt werden können.

---

Links und Quellen

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