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 😉

Linux – 10 FPS mehr auf Gnome

Einem kleinen Verdacht nachgehend, ich habe unter Linux die rohe Framerate von EVE Online auf Cinnamon und Gnome (X-Server) verglichen, beides mit den gleichen CPU/Memory/Grafikkarte/Grafikeinstellungen.

Nicht überraschend kam dabei raus, daß Gnome statte 10 FPS mehr beim internen FPS Counter von EVE schafft, als Cinnamon. Angefühlt hat sich das so schon immer, auch im 2D Betrieb. Wenn damals nicht der blöde Fenster-Zieh-Ruck-Bug unter Gnome gewesen wäre, der monatelange nicht behoben wurde und bei dem man wahnsinnig werden konnte, würde ich das als Desktop ja heute noch benutzen. Ich denke, daß der echte X-Server immer noch schneller ist, als Wayland. Um das zu prüfen, habe ich auch mit Gnome unter Wayland getestet.

Ergebnis: Gnome unter Wayland bringt auch nur 160 FPS in EVE, genau wie Cinnamon, welches wohl auch schon mit Wayland arbeitet.

Jetzt fragt sich der eine oder andere natürlich, wieso einen 10 FPS Unterschied bei 160 FPS stören, die könnte der Monitor ja eh nicht darstellen. Stimmt, kann er nicht, aber wenn man Let’s-Play Videos von Games macht, muß man Screenrecording einsetzen. Dies leidet unter der schlechteren Performance von Wayland, so daß man auf den Aufnahmen später ggf. störendes Tearing hat. Und das würde ich nicht auf Youtube zeigen wollen, weil das dem Image von Linux mal echt schaden würde. GGf. müßte man mal den extra für Games gemachten Capturemodus des OpenGL Hacks versuchen, der soll noch extra FPS bringen. Fragt sich nur, ob das auch das Tearing bekämpfen würde, weil ja nichts aus dem GFX Speicher ausgelesen würde. „Kommen Sie, Watson! Es lohnt sich vielleicht dieser Spur nachzugehen.“ 🙂

Fazit: Ein „Hoch“ auf den X-Server .. alt, aber schneller 😉

Linux – Packagekit – 4 GB freigeflusht

Wer nach vielen Monaten Platz auf seiner Platte braucht, der sollte unbedingt mal prüfen, wieviel Platz PackageKit über die Jahre/Monate so angesammelt hat.

Bevor ich meine Platte befreit habe, hatte das Verzeichnis bei mir statt der :

[root]# du -sh /var/cache/PackageKit/
3,6G /var/cache/PackageKit/
[root]# du -sh /var/cache/PackageKit/*
180M /var/cache/PackageKit/25
148M /var/cache/PackageKit/26
284K /var/cache/PackageKit/groups.sqlite
84M /var/cache/PackageKit/hawkey
3,2G /var/cache/PackageKit/metadata

lockere 8 GB belegt. Nach der Prozedur waren 4 GB mehr Platz vorhanden, was hilft 😉 Und so geht es als Root:

pkcon refresh force -c 86400

pkcon ist der PackageKit Console Client. Damit kann man einige nette Dinge anstellen, z.B. get-updates zeigt einem viel schneller Updates an, als dnf das tut, weil dnf sich das teilweise live holt und pk sich das aus dem obigen Cache zieht.

Mit „Refresh force“ werden alte Infos im Cache übergenagelt. Die Option -c gibt an, wie alt die Cachedaten maximal sein dürfen. Die anderen Optionen solltet Ihr  mal in Ruhe austesten.