Datenrettung bei EXT2,EXT3 und EXT4 – „rm -rf“

Unix Benutzer kennen den Befehl: „rm -rf“ im Root-Verzeichnis aufgerufen löscht gleich mal einen ganzen Server. Wir erhalten laufend Fälle, bei denen versehentlich oder absichtlich (meistens von Scriptkiddies) Verzeichnisse auf Linux-Servern gelöscht wurden.  Meistens handelt es sich noch um virtuallisierte Web-Server, klassisch mit Apache und MySQL oder PostgreSQL, mit einer ganzen Menge von Homepages von Kunden, teilweise mit Webshop, CMS, etc. Datensicherungen werden auch hier häufig vernachlässigt.

Das interessante bei Datenrettung mit EXT-Dateisystemen ist, dass sich die Dateisystemstruktur in jeder der EXT-Versionen (also EXT, EXT2, EXT3 und EXT4) wesentlich – zumindestens aus Datenrettersicht – verändert hat. Die Forschungs- und Entwicklungsabteilung von Attingo hat somit für jede EXT Version eigene Software entwickelt.

Nur einige Begründungen:
– seid EXT3 werden die INODEs beim Löschen genullt (somit ist eine einfache Zuordnung von fragmentierten Dateien nicht mehr möglich)
– EXT4 führt sogenannte EXTENTs ein
– sogenannte „indirect blocks“, „double indirect blocks“ und „tripple indirect blocks“ unterstützen eine erfolgreiche Datenrekonstruktion

In jeder EXT-Version erfolgt die Rekonstruktion von größeren, fragmentierten Dateien anders. Die gute Nachricht: Attingo kann bei EXT-Versionen gelöschte Dateien (auch fragmentierte) und Verzeichnisse rekonstruieren.

Die Vorgehensweise der Rekonstruktion von gelöschten Dateien unter EXT hängt von folgenden Faktoren ab:
– Welche EXT-Version ist im Einsatz?
– Wie groß ist die Datei (zwei bis drei unterschiedliche Ansätze zur Datenrekonstruktion, je nach EXT-Version)
– War Journaling aktiv?

Eines ist sicher – wir kennen kaum ein Dateisystem das für Datenretter optimiert wurde – und EXT steht in einer Rangliste ganz ganz weit unten (das soll natürlich nicht bedeuten, dass EXT ein schlechtes Dateisystem ist).

[Gesamt:0    Durchschnitt: 0/5]

Schreibe einen Kommentar