Verlorene Dateien wiederherstellen ext3 ext4 - Versionsgeschichte

Robi: Update ext4magic Version

2014-09-13T17:37:52Z

Update ext4magic Version

Robi: ext4magic Berlios.de -> SF.net

2014-05-17T14:35:22Z

ext4magic Berlios.de -> SF.net

Robi: Link Update

2013-05-19T17:10:58Z

Link Update

Itu: hm, durch, so wie's aussieht

2013-01-24T08:25:37Z

hm, durch, so wie's aussieht

Itu: dank xclip ....

2013-01-24T08:03:28Z

dank xclip ....

Itu: whitespace wieder raus?

2013-01-24T07:54:43Z

whitespace wieder raus?

Änderungen zeigen

Itu: hmpf, durch automatische ersetzung jede menge whitespace eingeschleppt ...

2013-01-24T07:47:11Z

hmpf, durch automatische ersetzung jede menge whitespace eingeschleppt ...

Itu am 24. Januar 2013 um 07:33 Uhr

2013-01-24T07:33:16Z

Änderungen zeigen

Itu: ~

2013-01-24T06:56:45Z

Itu am 23. Januar 2013 um 07:42 Uhr

2013-01-23T07:42:44Z

@@ Zeile 385: / Zeile 385: @@
 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.1.tar.gz/download ext4magic-0.3.1]  mit der Magic-Funktion für ext4<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.1 an. zu finden zB über [http://pkgs.org/search/?keyword=ext4magic pkgs.org]<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

@@ Zeile 347: / Zeile 347: @@
 -----
 ====ext4magic====
-Mit [http://openfacts2.berlios.de/wikide/index.php/BerliosProject:Ext4magic ext4magic] entsteht derzeit ein weiteres Konsolentool, 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 Mass möglich, soweit die Journaldaten dafür ausreichend sind. Unterstützt wird dabei sowohl ext3 als auch ext4.
+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.
@@ Zeile 359: / Zeile 361: @@
 ===== Weitere Möglichkeiten und Funktionen =====
-In Entwicklung dort ist 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.
+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.
@@ Zeile 370: / Zeile 372: @@
 # 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 aber nur bevor versucht wurde ein komplett defektes Filesystem mit fsck wieder zu reparieren).
+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).
@@ Zeile 377: / Zeile 379: @@
 ===== ext4magic Links und Dokumentation =====
-Informationen für das [http://openfacts2.berlios.de/wikide/index.php/BerliosProject:Ext4magic-Installation compilieren aus dem Quellcode], Benutzung sowie Hintergrundinformationen sind über die [http://developer.berlios.de/projects/ext4magic/ Projektseite] oder das [http://openfacts2.berlios.de/wikide/index.php/BerliosProject:Ext4magic Wiki] zu finden.<br>
+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.
-Einige ausführliche Howtos für [http://openfacts2.berlios.de/wikien/index.php/BerliosProject:Ext4magic-Howto typische Anwendungsfälle] sind im englischem Wiki zu finden.
+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 <!-- Stand? -->
+Aktueller Source Download
-:[http://prdownload.berlios.de/ext4magic/ext4magic-0.2.4.tar.gz ext4magic-0.2.4]  mit der Magic-Funktion für ext3<br>
+:[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://prdownload.berlios.de/ext4magic/ext4magic-0.3.1.tar.gz ext4magic-0.3.1]  mit der Magic-Funktion für ext4<br>
+:[http://sourceforge.net/projects/ext4magic/files/ext4magic-0.3.1.tar.gz/download ext4magic-0.3.1]  mit der Magic-Funktion für ext4<br>
-'''Neuigkeiten:''' Ein [http://developer.berlios.de/forum/forum.php?forum_id=35219 Front-End für ext4magic] speziell für kleine Rescue-Systeme steht derzeit<!-- Stand? --> für die ersten Usertests zur Verfügung.
+Einige Distributionen bieten fertige Community Pakete von ext4magic-0.3.1 an. zu finden zB über [http://pkgs.org/search/?keyword=ext4magic pkgs.org]<br>
 === Links und Quellen ===

@@ Zeile 382: / Zeile 382: @@
 Aktueller Source Download <!-- Stand? -->
 :[http://prdownload.berlios.de/ext4magic/ext4magic-0.2.4.tar.gz ext4magic-0.2.4]  mit der Magic-Funktion für ext3<br>
-:[http://prdownload.berlios.de/ext4magic/ext4magic-0.3.0.tar.gz ext4magic-0.3.0]  mit der Magic-Funktion für ext4<br>
+:[http://prdownload.berlios.de/ext4magic/ext4magic-0.3.1.tar.gz ext4magic-0.3.1]  mit der Magic-Funktion für ext4<br>
 Einige Distributionen bieten fertige Community Pakete 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 fertige Pakete online. Sieht auch [http://openfacts2.berlios.de/wikien/index.php/BerliosProject:Ext4magic#Installation Installationshinweise] im Wiki
 '''Neuigkeiten:''' Ein [http://developer.berlios.de/forum/forum.php?forum_id=35219 Front-End für ext4magic] speziell für kleine Rescue-Systeme steht derzeit<!-- Stand? --> für die ersten Usertests zur Verfügung.
 === Links und Quellen ===

@@ Zeile 269: / Zeile 269: @@
 ===== Installation von undelete =====
-Soweit nicht als Paket erhältlich sein sollte (Einige Distributionen bieten derzeit fertige Installationspakete an), bitte immer die aktuellste Version nehmen, hier wurde die Version 0.1.8 getestet. Kompilieren ist recht einfach, ähnlich ext3grep  <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''' 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'''
+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/downl
+   wget http://sourceforge.net/projects/extundelete/files/extundelete/0.1.8/extundelete-0.1.8.tar.bz2/download
 Archiv auspacken
@@ Zeile 285: / Zeile 285: @@
 Das Ergebnis ist eine ausführbare Datei mit Namen '''extundelete''' im Unterverzeichnis '''src/'''  <br>
-Zu installieren braucht man das Programm nicht unbedingt, es reicht wenn man es in ein Arbeitsverzeichnis kopiert oder man könnte es auch dort an Ort und Stelle ausführen, wo es kompiliert wurde. Dadurch kann es, wenn man es nur einmalig benötigt wird, anschließend auch schnell wieder gelöscht werden.
+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/
@@ Zeile 308: / Zeile 308: @@
 '''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
-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
-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
 test8/datei_follow.log
@@ Zeile 328: / Zeile 328: @@
 test8/test6/dir1/dir2/dir3/dir4
 test8/test6/dir1/dir2/dir3/dir4/Testdatei.txt </pre>
-Achtung: Der Befehl ist nicht zu verwechseln 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
-Alle als gelöscht zu findende Dateien restoren.
+Alle als gelöscht zu findenden Dateien restaurieren.
   ./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
@@ Zeile 342: / Zeile 342: @@
 '''Hinweise :'''
-Allgemein gilt das selbe wie bei ext3grep.
+Allgemein gilt dasselbe wie bei ext3grep.
@@ Zeile 351: / Zeile 351: @@
 ====ext4magic====
-Mit [http://openfacts2.berlios.de/wikide/index.php/BerliosProject:Ext4magic ext4magic] entsteht derzeit ein weiteres Konsol Tool, welches das recovern von Dateien aus Journaldaten ermöglicht. Es baut auf den Erfahrungen von ext3grep und extundelete auf, und geht dabei ein paar Schritte weiter. Es ermöglicht auch die Wiederherstellung der User- und Zugriffsrechte, der Zeitstempel, unterstützt mit Ausnahme von Sockets alle Dateitypen und auch Hardlinks. Auch das Wiederherstellen von Dateiattributen ist möglich und kann optional beim compilieren aktiviert werden. Das Wiederherstellen überschriebener Dateien/Verzeichnisse oder älterer Dateiversionen ist in gewissen Masse möglich, soweit die Journaldaten dafür ausreichend sind. Unterstützt wird dabei sowohl ext3 als auch ext4.
+Mit [http://openfacts2.berlios.de/wikide/index.php/BerliosProject:Ext4magic ext4magic] entsteht derzeit ein weiteres Konsolentool, 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 Mass möglich, soweit die Journaldaten dafür ausreichend sind. Unterstützt wird dabei sowohl ext3 als auch ext4.
-Das Programm hat eine Vielzahl von Anzeige Optionen und ermöglicht somit auch Untersuchungen am Filesystem. Somit können über die Nutzung der Journaldaten Manipulationen und Änderungen an Dateien und Verzeichnissen ermittelt und verfolgt werden, soweit sich die Daten dazu noch im Journal befinden. Die Vielzahl der Funktionen macht dieses Programm jedoch in der Anwendung nicht ganz einfach.
+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.
@@ Zeile 359: / Zeile 359: @@
 ===== Weitere Möglichkeiten und Funktionen =====
-In Entwicklung dort ist ein mehrstufiges Recover welches speziell für den Fall eines versehentlich rekursivem Löschens abgestimmt ist. Wird das Filesystem nach einem solchem Löschvorgang baldmöglichst umountet und nicht weiter benutzt hat man mit den neuen Magic-Funktionen (derzeit verfügbar für ext3 in Versionen 0.2.x und für ext4 in Versionen 0.3.x ) sehr gute Chancen auch Dateien wiederherstellen zu können, von denen keine alte Inodekopie mehr vorhanden sind. Ermöglicht wird das durch ein mehrstufiges Verfahren. Im ersten Schritt werden alle Dateien wiederhergestellt die aus Inodekopien im Journal gewonnen werden können. Nachfolgend wird mit einem neuen sehr speziell auf das Filesystem abgestimmten [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 dem Journaldaten, welche während des Löschens geschrieben wurden, versucht die Datenblöcke gezielt zu ermitteln, die gelöscht worden sind und es werden auch alle Datenblöcke übersprungen die schon durch das Recovern der Inodekopien aus dem Journal ihre Verwendung wieder gefunden haben. Damit ist auch effektives Wiederherstellen der Daten in nur teilweise gelöschten Filesystemen möglich. Diese neuen Funktionen nutzen unter anderem auch filesystemtypischen Metablöcke für das Zusammenbauen der Dateien. Solche Daten werden von den meisten Recovertools weniger bis gar nicht genutzt, da viele dieser Programme darauf abgestimmt wurden, möglichst universell auf viele unterschiedlichen Filesysteme zu arbeiten.
+In Entwicklung dort ist 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.
@@ Zeile 368: / Zeile 368: @@
 # es wird so gut es geht vermieden solche Datenbereiche auszuwerten, die mit dem letztem Löschvorgang nichts zu tun haben
 # Datenbereiche werden nicht mehrfach recovert und der Datenschrott beim Recovern wird verringert
-# zT werden fragmentiert abgelegte Dateien, die sonst sehr schwierig zu recovern sind, gefunden
+# 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 Filesysteme versucht werden kann, noch Dateien zu retten (funktioniert aber nur bevor versucht wurde ein komplett defektes Filesystem mit fsck wieder zu reparieren).
+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 aber nur bevor versucht wurde ein komplett defektes Filesystem mit fsck wieder zu reparieren).
@@ Zeile 380: / Zeile 380: @@
 Einige ausführliche Howtos für [http://openfacts2.berlios.de/wikien/index.php/BerliosProject:Ext4magic-Howto typische Anwendungsfälle] sind im englischem Wiki zu finden.
-Aktueller Source Download
+Aktueller Source Download <!-- Stand? -->
 :[http://prdownload.berlios.de/ext4magic/ext4magic-0.2.4.tar.gz ext4magic-0.2.4]  mit der Magic-Funktion für ext3<br>
 :[http://prdownload.berlios.de/ext4magic/ext4magic-0.3.0.tar.gz ext4magic-0.3.0]  mit der Magic-Funktion für ext4<br>
-Einige Distributionen bieten fertige Community Pakete an. zu finden zB über. [http://pkgs.org/search/?keyword=ext4magic pkgs.org]<br>
+Einige Distributionen bieten fertige Community Pakete 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 fertige Pakete online. Sieht auch [http://openfacts2.berlios.de/wikien/index.php/BerliosProject:Ext4magic#Installation Installationshinweise] im Wiki
-'''Neuigkeiten:''' Ein [http://developer.berlios.de/forum/forum.php?forum_id=35219 Front-End für ext4magic] speziell für kleine Rescue Systeme steht derzeit für die ersten Usertests zur Verfügung.
+'''Neuigkeiten:''' Ein [http://developer.berlios.de/forum/forum.php?forum_id=35219 Front-End für ext4magic] speziell für kleine Rescue-Systeme steht derzeit<!-- Stand? --> für die ersten Usertests zur Verfügung.

@@ Zeile 28: / Zeile 28: @@
-Änderungen am Filesystem werden in aller Regel nicht momentan ausgeführt. Das System nimmt den Filesystem Cache und buffert die Daten temporär. Automatisch wird ein "sync" alle paar Sekunden dann die Daten wirklich auf die Platte schreiben. Wird zB eine Datei verändert und unmittelbar danach sofort die ganze Datei gelöscht, dann wird die Änderung der Datei eventuell gar nicht erst auf die Platte geschrieben, sondern nur die Löschung. Recovern können wir nur das, was auf der Platte steht und nicht das was niemals auf die Platte geschrieben wurde.
+Ä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.
@@ Zeile 86: / Zeile 86: @@
 # 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 wieder recovern können. Also sollte man sich die alten Journaldaten nicht noch unnötig überschreiben, wenn man ein solches Programm nutzen möchte. Je früher man das Filesystem oder zumindestens das Journal jetzt aushängt und nicht weiter benutzt, desto mehr Dateien werden solche Programme finden können.
+# 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.
@@ Zeile 213: / Zeile 213: @@
   ./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
@@ Zeile 219: / Zeile 219: @@
   ./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
@@ Zeile 225: / Zeile 225: @@
 '''Hinweise:'''
 # '''Das Programm ist und bleibt "Beta"'''
-# Es geht hier nur ext3, wenn ein ext3 Filesystem mit ext4 beschrieben wurde, oder nach ext3 konvertiert wurde, wird es nicht funktionieren oder nur unzureichend Ergebnisse liefern
+# 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 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 der Stand vor dem letztem Löschvorgang einer Datei hergestellt.
-# Nicht wirklich jede Datei wird sich jederzeit auch so wieder recovern lassen, Ein Backup ersetzt dieses Tool also keinesfalls
+# Nicht wirklich jede Datei wird sich jederzeit auch so wiederherstellen lassen, Ein Backup ersetzt dieses Tool also keinesfalls
-# Möglichst nicht erst viel im Filesystem weiter schreiben bevor man recovert
+# Möglichst nicht erst viel im Filesystem weiter schreiben
 # Die wiederhergestellten 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.
-# Gerätedateien Pipes uä werden nicht unterstützt
+# Gerätedateien Pipes u.ä. 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.)
@@ Zeile 251: / Zeile 251: @@
 '''Vorteile''' : <br>
-Sehr brauchbare Laufzeiten auch in großen Filesystemen. Flexibel sowohl auf ext3 wie ext4. Analoge Funktionen und ebenfalls weitest gehende analoge Befehls-Optionen zu ext3grep. Durch die Benutzung der Libraryfunktionen erhält es automatisch die notwendige Flexibilität für eine gute Unterstützung des ext3/4 Filesystems. Unterstützung auf für Big Endian. Es können hiermit auch gezielt Verzeichnissbäume und Dateilisten wiederhergestellt werden.
+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.
@@ Zeile 257: / Zeile 257: @@
 '''kleine Mängel''' : <br>
-Es sind noch längst nicht alle ursprünglich beabsichtigten Funktionen implementiert. Die Weiterentwicklung scheint mehr oder weniger eingeschlafen zu sein. Derzeit können nur der reine Dateiinhalt wiederhergestellt werden. Nützliche Zusatzfunktionen, analog ext3grep, sind leider derzeit nicht implementiert. extundelte ist derzeit nicht mit den aktuellsten Versionen von libext2fs (1.42) nutzbar.
+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>
-Projekt mit guten Potential. Einfach in der Anwendung und einige Test und  Wiederherstellung von Dateien und Verzeichnissen sowohl auf ext3 wie ext4 begeistern jedoch, auch wenn mehr oder weniger "nur" die reinen Dateidaten mit ihrem Namen und Path möglich sind. Die Datendateien sind das Wichtigste, das scheint prima zu funktionieren. Leider bleiben Fragen zu Problemen selbst in den offiziellen Mailinglisten oftmals unbeantwortet.
+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 86: / Zeile 86: @@
 # als nächstes mit "kleinen Befehlen" möglichst herausfinden: Geht überhaupt noch was? Welches Filesystem, welcher Verzeichnisbaum ist betroffen? was sind/waren dort für Dateien und Daten? Welche Prozesse/User/Dienste/Server greifen dort zu, welche davon könnten dort auch schreiben? Kann/darf ich diese Programme beenden, oder noch schlimmer, muss ich sie etwa beenden, weil ihnen Dateien unter dem Hintern weggelöscht wurden und sie jetzt deshalb nur noch Fehler produzieren und die Logdateien vollmüllen?
 # Wichtig nachdem klar ist was in etwa alles gelöscht wurde: das entsprechenden Filesystem so gut es geht vor weiteren Schreibaktionen schützen: Wenn möglich Rechner beruhigen (zB Singleusermodus wenn man genügend Konsolenrfahrung dafür hat), ansonsten: Programme die schreibend zugreifen möglichst beenden, nicht benötigte Programme und Fenster schließen, keine weiteren Programme starten die auf dieses Filesystem zugreifen könnten. Bei betroffenen Homeverzeichnissen eventuell, neuen User anlegen dessen Home dann auf dem Rootfilesystem angelegt wird und als dieser User weiterarbeiten, Ziel ist möglichst das entsprechende Filesystem auf readonly zu remounten noch besser wenn möglich das Filesystem komplett umounten. Vorsichtshalber in der /etc/fstab Schreiberlaubnis für die betroffene Partition auch vorläufig entfernen.
-# Was oftmals übersehen wird. Es handelt sich um ein Journalfilesystem. Das Journal wird auch weiterhin benutzt auch wenn man nichts in das Filesystem schreibt. ZB. wenn Dateien gelesen werden, dabei wird ein neuer a-time Zeitstempel in die Inode eingetragen. Auch solche Aktionen laufen über das Journal. Würde jetzt zB mit einem "find" der Rest des Filesystems durchsucht werden, würde je nachdem wie viel vom Filesystem nach dem Löschen noch übrig ist, eventuell eine ganze Menge ins Journal geschrieben. Jede dieser Schreibaktionen im Journal wird dabei alte Journaldaten überschreiben. Und es gibt Recoverprogramme die aus alten Journaldaten hervorragend wieder recovern können. Also sollte man sich die alten Journaldaten nicht noch unnötig überschreiben, wenn man ein solches Programm nutzen möchte. Je früher man das Filesystem oder zumindestens das Journal jetzt aushängt und nicht weiter benutzt, desto mehr Dateien werden solche Programme finden können.
+# 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 wieder recovern können. Also sollte man sich die alten Journaldaten nicht noch unnötig überschreiben, wenn man ein solches Programm nutzen möchte. Je früher man das Filesystem oder zumindestens das Journal jetzt aushängt und nicht weiter benutzt, desto mehr Dateien werden solche Programme finden können.
 # Informationen sammeln: Parititionsgrößen, Mountpoints, Filesystemtyp, wie viel ist im Moment belegt, wie viel könnte es vorher gewesen sein, Datentypen, Homeverzeichnisse anderer User betroffen? Dann diese auch informieren und auch dort Informationen sammeln. Wenn möglich welche Verzeichnisstruktur war auf der Platte, bzw. was ist davon verschwunden. Wo habe ich im Rechner eventuell noch Platz, um temporär Dateien zwischenzuspeichern. Eventuell muss man sich Prioritäten setzen: was brauche ich an Dateien unbedingt wieder; auf was kann ich notfalls verzichten; was wäre eventuell ganz unwichtig.
 # Ist das betroffene Filesystem soweit beruhigt, dass möglichst nichts mehr neu geschrieben werden kann (auch nicht nach einem eventuellem reboot) und die wichtigsten Informationen eingesammelt sind, erst dann geht es weiter.
@@ Zeile 102: / Zeile 102: @@
 === Dateien anhand ihres Type mit einem Flächenscan aus den Datenblöcken wieder gewinnen ===
-Die nackten Datenblöcke der Dateien bleiben als solche bei den allermeisten Filesystemen auch beim löschen vollkommen intakt auf der Festplatte zurück. Man muss eine Platte schon gezielt überschreiben, damit man nicht mehr an alte Dateien herankommt. Ließt man die gesamte Partition Block für Block aus und schaut sich die einzelnen Blöcke insbesondere den Blockanfang an, wird man dort an bestimmten Eigenschaften den Beginn von bestimmten Dateitypen erkennen können. Ist die Datei größer als die Blockgröße, dann wird man wahrscheinlich im nächsten Block die Fortsetzung dieser Datei finden. Auch das Ende vieler Dateien kann man erkennen. Meist ist der Rest hinter einer Datei mit Nullen bis zum Blockende gefüllt. Es ist also möglich hintereinander liegende Datenblöcke zu Dateien zusammen zu bauen. Wenn das ein einigermaßen intelligentes Tool macht, und dieses auch noch ein bisschen Ahnung vom Filesystem hat, dann hat man sogar die Chance auch Dateien aus Blöcken wiederzufinden und zusammen zu bauen, die auf der Platte fragmentiert vorliegen. Tools die so nach verlorenen Dateien suchen gibt es eine ganze Menge.
+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 Datentype hinweist. Diese Tools sind aber nicht in der Lage den gefundenen Dateien allen ihre ursprünglichen Namen wieder zugeben, geschweige denn zu entscheiden, in welches Verzeichnis gehört die Datei und welchem User hat die Datei gehört. Nach dem Einsatz solcher Tools kann man sich nicht selten Stunden und Tage damit befassen, Dateien zu sichten, zu sortieren und ihnen neue Namen zu geben. Eventuell helfen Scripte dabei. Allerdings sind die Probleme dabei so vielfältig und in jedem Fall anders gelagert, das es dazu nicht wirklich etwas universelles gibt. Dieses Verfahren 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.
+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 111: / Zeile 111: @@
 ==== 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 Filesystem angewiesen, kann also Dateien auch noch finden wenn das Filesystem schwer beschädigt oder eventuell neu 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.
@@ Zeile 133: / Zeile 133: @@
 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 können jetzt über die Links zu den Datenblöcken, die Datei wieder hergestellt werden. Die anderen Eigenschaften der gelöschten Datei stehen auch in dieser Inode. Die Datenblöcke auf die diese Inodekopie verweist, sind zwar im Filesystem derzeit als "frei verfügbar" markiert, die Wahrscheinlichkeit das sie jedoch noch nicht anderweitig benutzt wurden, ist groß. Damit könnte jetzt problemlos eine Kopie der gelöschte Datei erzeugt werden. Programme die das können sind '''ext3grep''' ; '''extundelete''' ; '''ext4magic'''
+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.

@@ Zeile 1: / Zeile 1: @@
-Wird eine Datei gelöscht, dann bleiben die Datenblöcke dieser Datei von der Löschung unberührt. Die Löschung der Datei erfolgt in den Verwaltungsdaten ( [[Inode]]) der Datei, sowie in den Verzeichnissen, wo Inodenummer mit dem Dateinamen verknüpft ist. In einem ext3/4 Filesystem werden die Daten in der Inode soweit gelöscht, das es schwierig wird eine 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ü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]
 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 46: / Zeile 46: @@
 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. Diese Verhalten kann man zum Beispiel auch bemerken, wenn man versucht eine überlange aktuelle Logdatei zu löschen. Man hat eine riesengroße Datei zwar gelöscht, sieht sie auch nicht mehr mit '''"ls"''', aber der Speicherplatz dieser Datei wird einfach nicht freigegeben. Die Logdatei ist dann immer noch von einem Prozess geöffnet der hier nach wie vor in die scheinbar schon gelöschte Datei weiter schreibt. Die Datei kann also durchaus noch weiter anwachsen. Erst wenn dieser Prozess beendet wird, dann wird der Plattenplatz den diese Datei belegt hat, wirklich freigegeben.
+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.
@@ Zeile 78: / Zeile 78: @@
 <!-- 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 einer Daten und hat es auch schon erfolgreich getestet, dass er damit jederzeit alles wiederherstellen kann. Deshalb das folgende hier nur theoretischer Art. ;-) <br>
+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
+# 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 und Rechner beruhigen (zB Singleusermodus wenn man genügend Konsolerfahrung dafür hat), ansonsten: Programme die schreibend zugreifen möglichst beenden, nicht benötigte Programme und Fenster schließen, keine weiteren Programme starten die auf dieses Filesystem zugreifen könnten. Bei betroffenen Homeverzeichnissen eventuell, neuen User anlegen dessen Home dann auf dem Rootfilesystem angelegt wird und als dieser User weiterarbeiten, Ziel ist möglichst das entsprechende Filesystem auf readonly zu remounten noch besser wenn möglich das Filesystem komplett umounten. Vorsichtshalber in der /etc/fstab Schreiberlaubnis für die betroffene Partition auch vorläufig entfernen.
+# Wichtig nachdem klar ist was in etwa alles gelöscht wurde: das entsprechenden Filesystem so gut es geht vor weiteren Schreibaktionen schützen: Wenn möglich Rechner beruhigen (zB Singleusermodus wenn man genügend Konsolenrfahrung dafür hat), ansonsten: Programme die schreibend zugreifen möglichst beenden, nicht benötigte Programme und Fenster schließen, keine weiteren Programme starten die auf dieses Filesystem zugreifen könnten. Bei betroffenen Homeverzeichnissen eventuell, neuen User anlegen dessen Home dann auf dem Rootfilesystem angelegt wird und als dieser User weiterarbeiten, Ziel ist möglichst das entsprechende Filesystem auf readonly zu remounten noch besser wenn möglich das Filesystem komplett umounten. Vorsichtshalber in der /etc/fstab Schreiberlaubnis für die betroffene Partition auch vorläufig entfernen.
-# Was oftmals übersehen wird. Es handelt sich um ein Journalfilesystem. Das Journal wird auch weiterhin benutzt auch wenn man nichts in das Filesystem schreibt. ZB. wenn Dateien gelesen werden, dabei wird ein neuer a-time Zeitstempel in die Inode eingetragen. Auch solche Aktionen laufen über das Journal. Würde jetzt zB mit einem "find" der Rest des Filesystems durchsuchen werden, würde je nachdem wie viel vom Filesystem nach dem Löschen noch übrig ist, eventuell eine ganze Menge ins Journal geschrieben. Jede dieser Schreibaktionen im Journal wird dabei alte Journaldaten überschreiben. Und es gibt Recoverprogramme die aus alten Journaldaten hervorragend wieder recovern können. Also sollte man sich die alten Journaldaten nicht noch unnötig überschreiben, wenn man ein solches Programm nutzen möchte. Je früher man das Filesystem oder zumindestens das Journal jetzt aushängt und nicht weiter benutzt, desdo mehr Dateien werden solche Programme finden können.
+# Was oftmals übersehen wird. Es handelt sich um ein Journalfilesystem. Das Journal wird auch weiterhin benutzt auch wenn man nichts in das Filesystem schreibt. ZB. wenn Dateien gelesen werden, dabei wird ein neuer a-time Zeitstempel in die Inode eingetragen. Auch solche Aktionen laufen über das Journal. Würde jetzt zB mit einem "find" der Rest des Filesystems durchsucht werden, würde je nachdem wie viel vom Filesystem nach dem Löschen noch übrig ist, eventuell eine ganze Menge ins Journal geschrieben. Jede dieser Schreibaktionen im Journal wird dabei alte Journaldaten überschreiben. Und es gibt Recoverprogramme die aus alten Journaldaten hervorragend wieder recovern können. Also sollte man sich die alten Journaldaten nicht noch unnötig überschreiben, wenn man ein solches Programm nutzen möchte. Je früher man das Filesystem oder zumindestens das Journal jetzt aushängt und nicht weiter benutzt, desto mehr Dateien werden solche Programme finden können.
-# Informationen sammeln: Parititionsgrößen, Mountpoints, Filesystemtype, wie viel ist im Moment belegt, wie viel könnte es vorher gewesen sein, Datentypen, Homeverzeichnisse anderer User betroffen? dann diese auch informieren und auch dort Informationen sammeln. Wenn möglich welche Verzeichnisstruktur war auf der Platte, bzw. was ist davon verschwunden. Wo habe ich im Rechner eventuell noch Platz, um temporär Dateien zwischenzuspeichern. Eventuell muss man sich Prioritäten setzen: was brauche ich an Dateien unbedingt wieder; auf was kann ich notfalls verzichten; was währe eventuell ganz unwichtig.
+# 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, das möglichst nichts mehr neu geschrieben werden kann (auch nicht nach einem eventuellem reboot) und die wichtigsten Informationen eingesammelt sind, erst dann geht es weiter.
+# 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.
+# 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.