QPhotorec und das Danach

Ja, jetzt ist es passiert. Ich habe aus Versehen ein paar Bilder gelöscht. Zum Glück hatte hatte ich von früher bereits QPhotoRec auf dem Rechner, so daß ich gleich loslegen konnte.

Die Konstellation

Auf einer reinen Datenplatte waren PNG Bilder, die aber keine PNGs sondern JPEGs waren (danke Tello Devs, Ihr seid echte CodeMonkeys wie Sie im Buche Tannenbaum stehen 🙁 ). Die sollten zwecks verscripteter Umbenennung ( falls das mal wer braucht: for i in *.png;do mv $i ${i%png}jpg; done ) und Voransicht auf eine SSD verschoben werden und dann, nach der anschliessenden Bearbeitung, wieder auf die Datenplatte zurück. So der Plan.

Jetzt was wirklich passierte. Die Bilder wurden auf die SSD verschoben, aber nicht aus Listenansicht des Verzeichnisses, sondern aus der Nemo eigenen Suchergebnisliste (von PNGs). Beim Verschieben ist das Programm ganz clever und findet dann die gesuchten Bilder lustigerweise gleich wieder, weswegen ich dachte, ich hätte COPY statt MOVE benutzt. Da das in Nemo nur eine SHIFT-Taste weit auseinander liegt, sahs ich einem Irrtum auf .. und weg waren die Bilder auf der Zielpartition und der Quelle. Kann passieren.

Da es eine Datenpartition war, bestand keine Gefahr das die gelöschten Bilder überschrieben werden, also kam QPhotoRec zum Einsatz. 3,8 Milliarden Blöcke später lagen 181.685 PNG und 3.106 JPG Bilder auf der Zischenlagerplatte ( nie auf die zu rettende Partition zurücksichern! Wichtig !)  verteilt auf 370+ Ordner! und natürlich 99,9% Schrott. Für Euch noch wichtig, QPhotoRec kann man auf bestimmte Dateientypen einschränken, sonst wäre da noch sehr viel mehr gekommen 😉

Wie man den Datenwust jetzt optimal ignoriert

180k Dateien.. von Hand durchsehen? Wohl kaum. Daher zwei Wege das zu Beschleunigen:

1. „file“ auf eine Datei gleichen Typs anwenden:

1539788463675.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1×1, segment length 16, Exif Standard: [TIFF image data, little-endian, direntries=4, manufacturer=RYZE, model=RZ001, software=v01.04.35.01], baseline, precision 8, 2592×1936, frames 3

Da die Bilder der Drohne in meinem Fall alle die gleiche Auflösung haben, kann man jetzt einfach so suchen:

file recup_dir.?/* | grep 2592×1936
file recup_dir.??/* | grep 2592×1936
file recup_dir.1??/* | grep 2592×1936
file recup_dir.2??/* | grep 2592×1936
file recup_dir.3??/* | grep 2592×1936

Wenn in einem Verzeichnis ein Bild der Drohnenauflösung zu finden ist, würde es angezeigt werden.

2. „find recup_dir.* -size +200k -exec gnome-open {} \;“

Der Befehl sucht nach Dateien > 200kb und zeigt die mit gnome-open an. Ok, ist nur ein Befehl mit einigen Annahmen, aber jeder Menge Treffer, die man selbst durchsehen muß. Es schränkt aber das zu durchsuchende Material auf ein paar Treffer ein. Kommt natürlich darauf an, was QPhotoRec so alles gefunden hat.

Ich habe meine Bilder wieder und Ihr ein paar Ideen, wie man nach dem Recovery effizient an die Sache rangeht. Kleine Anmerkung: Nemo hat einen Papierkorb, wäre nicht passiert, wenn man den benutzt hätte 🙂

Linux – Datarecovery mit QPhotoRec

Wer kennt das nicht ? Eine Datei aus Versehen gelöscht und wie kommt man an die jetzt wieder ran ? Da kommt QPhotoRec ins Spiel.

Bevor wir uns aber dem Recoverytool zuwenden, müssen wir erst mal klarstellen, was beim Löschen von Dateien passiert.

Festplatten haben physikalische Sektoren fester Länge, welche die Elektronik der Festplatte mit Hilfe des Schreiblesekopfes einzeln ansprechen kann. Das alleine hilft aber beim Speichern von Daten nicht. Erst das Dateisystem(Filesystem) erzeugt eine logische Struktur in diesen Datenblöcken, so daß man Dateien mit Daten überhaupt erst anlegen und verwalten kann.

Dazu speichert sich das Filesystem eine Liste mit bereits belegten Speicherblöcken und ein Baumdiagramm der Dateistruktur, was z.B. eine verlinkte Liste von Namen sein kann, zu denen noch der erste Block der Datenblöcke vermerkt ist. Ohne weiter ins Detail zu gehen, speichert so ein Filesystem noch eine ganze Menge an anderen Daten, z.b. Zugriffsrechte, Erstellungsdatum, Länge usw. .

Im Prinzip besteht ein Directoryeintrag aka Filename nur aus einer Referenz auf einen Datenblock und eine Referenz auf einen Block mit Metainformationen wie Name, Datum usw.  . Wenn man jetzt in dem „Directory“ in dem sich die Datei „befindet“ die Referenzen zu diesen beiden Blöcken löscht, und die Blöcke des Datenteils der Datei aus der Liste der belegten Blöcke löscht, ist die Datei „weg“, aber die Daten sind noch auf der Platte gespeichert. Das Filesystem weiß bloß nichts mehr darüber. Der Inhalt der ehemaligen Datei ist aber noch da, bis die Datenblöcke neu beschrieben werden.

Das Linuxproblem

Und da kommt uns jetzt Linux in den Weg, denn ein Linuxsystem schreibt laufend neue Informationen auf mindestens die Systemfestplatte, so daß es i.d.R. nicht lange dauert, bis so ein freier Datenblock mit neuen Infos überschrieben wird.

D.b. wir müssen schnell sein und wir müssen weise handeln.

Als ersten zieht man mal den Strom vom PC ab!

WAAASSSSS !?!?!?!

„Das kannst Du nie im Leben ernst meinen!“

Ich fürchte doch, kommt aber drauf an, wo man was gelöscht hat 🙂 Auf der Systemplatte werden laufend Dateien geschrieben. D.b. das es je nach freiem Platz, schnell geht, bis die ehemaligen Dateiblöcke überschrieben sind.

Bei modernen Installationen sind /home/ und einige andere Mountpoints nicht auf der Systempartition, sondern auf einer eigenen Partition. Wenn man in /home/ was gelöscht hat, dann braucht Ihr den Rechner natürlich nicht gleich vom Strom trennen! Hier könnt Ihr den Teil mit Abschalten und von Livedisk booten überspringen und gleich zum Recovery übergehen.

Wenn man aber etwas wichtiges auf der Systemplatte/partition gelöscht hat, muß man schnell sein. Ein verschärfendes Problem ist, daß beim Runterfahren eines Computers auch Daten geschrieben werden, z.b. merken sich diverse Programme wo sie waren, als Sie beendet waren. z.B. FireFox 🙂 Wäre das nicht fatal, wenn man beim Runterfahren um Daten zu retten, genau diese Daten mit eigentlich nutzlosen Infos übernageln würde ?! Zusätzlich wird der Inhalt des Filesystemramcaches auf die Platte gesynct, was VIEL Schreiben beinhalten kann. Um das nicht stattfinden zu lassen, bleibt leider nur der harte Reboot.

ACHTUNG: Sie machen das auf eigene Gefahr, DENN weil genau z.b. das Syncen des Filesystemcaches aus dem Ram auf die Platte nicht stattfindet UND Schreibzugriffe im laufenden Betrieb unterbrochen werden, KANN (und WIRD) das Filesystem weiter beschädigt. Dies KANN zu einem Datenverlust führen.  Journalingfilesysteme gibt es nicht umsonst, benutzt die, die haben genau dagegen wirksame Mechanismen!

Der harte Reset

Damit beim Booten die Datenblöcke nicht überschrieben werden, weil z.b. Tempdateien erzeugt werden, MUß man von einer LiveDisk starten, idealerweise mit der aktuellen Rettungscd, wo QPhotoRec schon drauf ist.

Da QPhotoRec ROOT Rechte braucht, müßt Ihr wissen wie Ihr dort dann ROOT werdet und QPhotoRec aus der Root-Bashshell startet!

Das Recovery

Ihr startet also QPhotoRec als Root und seht das :

Photorec

Schritt 1:

Mit der Selectbox das Medium auswählen, daß man „retten“ will. Oben ist das /dev/sdd mit einem USB Stick.

Schritt 2 :

Die Partition aussuchen in der man was gelöscht hat, ODER gleich die ganze Platte durchsuchen lassen. Liegt bei Euch. Alles durchsuchen zu lassen dauert eine ganze Weile länger, fördert i.d.R. aber auch mehr zu Tage.

Schritt 3 :

Das Speichermedium für die geretteten Daten auswählen , im Beispiel oben /media/recovery .

LOGISCHERWEISE rettet man seine Daten NICHT auf das Medium von dem Sie stammen, weil man dabei natürlich die freien Datenblöcke übernagelt! Also IMMER auf eine andere Partition/Platte/USB-Stick/Cloud-Speicher retten.

Schritt 4 :

„SEARCH“ drücken und Kaffee trinkengehen.

Wenn man fertig ist, sieht das so aus :

Ergebnis von Photorec

Wenn man jetzt QPhotoRec beendet, kann man in dem Speicherort nachsehen was man bekommen hat.

Es wird nicht nur die eine Datei dabei sein und, todsicher wird die nicht den gleichen Namen haben wie früher. Akzeptierts einfach, der Name ist für immer verloren 🙂 Ihr könnt Euch nur an dem Dateitype (z.b. der Endung) und der Größe orientieren. Da immer mal wieder was auf einer Platte gelöscht wird, besteht auch immer die Möglichkeit was zu finden, was man nicht gesucht hat. Das Recoverytool kann das natürlich nicht wissen, es sucht nur nach zusammenhängenden Dateiblöcken.

Da QPhotoRec nur ein einfaches Programm ist, ist der Beitrag hier zu Ende.

Kleiner Hinweis: USB Sticks sind aufgrund der Hardware nicht die besten Beispielmedium zum Retten, aber bevor ich das erklärt habe, ist Ostern 🙂 Wer es trotzdem wissen will, liest es hier nach : Mit LUKS einen USB Stick verschlüsseln

Und bevor Ihr ein Problem habt, daß es beim Retten nur noch schlimmer macht, setzt einfach Backups ein 😉