Eine kleine Geschichte zur Datenrettung bei LVM2 und LUKS.

Nachdem ich es heute geschafft habe, meine “Ersatz” Festplatte (Ersatz während die SSD gerade auf Garantie getauscht wird) versehentlich teilweise zu löschen, in dem ich auf dem falschen Gerät – nämlich auf der HDD – ein Secure Erase gemacht habe, dachte ich, ich erzähl euch mal kurz wie die anschließende Datenrettung ablief.

Nachdem ich den Secure Erase gestartet hatte, bemerkte ich den Fehler natürlich innerhalb einiger Sekunden und brach den Secure Erase (der auf der HDD ca. 45 Minuten dauert) ab (durch Stecker ziehen, anders ging es nicht), aber natürlich war erst mal alles kaputt … LVM (eigentlich LVM2) kaputt, LUKS Verschlüsselung kaputt, kurz: nichts ging mehr.

Hab mich natürlich riesig gefreut, kann sich ja jeder vorstellen. An für sich ist es kein so großes Problem, ich hatte ja ein Backup (welches wenige Tage alt war), somit war nicht sooo viel verloren. Allerdings lagen im Homeverzeichniss ein paar Bilder, die ich seitdem geschossen habe und gerne wieder hätte.

Was stand also zur Auswahl?
a) Recovery der CF Karte der Kamera(da liegen irgendwo verstreut normalerweise auch die Dateien nach dem Löschen)
b) Recovery der HDD

Eigentlich wäre a) schneller gegangen, hat aber zwei Nachteile: Oft sind die Dateien danach teilweise korrupt und fast immer fehlen die Dateinamen. Bei der Menge an Bildern wird es ein riesen Spaß sie zuzuordnen.
Also probierte ich erstmal b), denn die Daten dürften wohl noch da sein, da der secure erase wohl erstmal die vorderen Partitionen (/boot usw.) killt. Nimmt man sich die 45 Minuten Dauer (sagt hdparm -I) zu Herzen, so kann also nicht viel mehr als 1/45 fehlen. Innerlich habe ich schon extundelete (ein super Tool zur Datenrettung auf ext2/3/4 Laufwerken) bereit gestellt, aber dann fiel mir auf: Ups, du nutzt ja Luks und LVM2.

Also ist der erste Schritt das Lukslaufwerk zu reparieren, kein Problem, ich fertige ja immer Headerbackups an.
Problem: Das Laufwerk wird gar nicht mehr erkannt. Mhhpf! Weder fdisk noch sonst ein Programm findet es, lsusb zeigt es aber als angesteckt.
Nach längerer Denkpause fiel mir ein, dass es vermutlich noch “locked” ist, weil der Secure Erase ja nur unterbrochen wurde.
Also wieder “unlocken” und das Sicherheitsgedöhns abschalten mit hdparm:

sudo hdparm -I /dev/xyz
sudo hdparm --user-master u --security-unlock Eins /dev/xyz
sudo hdparm --user-master u --security-disable Eins /dev/xyz
sudo hdparm -I /dev/xyz

Nach einmal kurz an- und abstecken wurde sie dann wieder korrekt erkannt.
Ausgefüht hatte ich den Secure Erase übrigens mit diesem Tutorial, daher auch das Passwort “Eins”. Die Manpage von hdparm gibt ebenfalls eine gute Übersicht der Befehle. hdparm -I dient übrigens nur zur Infoanzeige.

Noch ein Problem: Der MBR ist weg .. naja ich wusste noch ziemlich genau wieviel MB meine Partitionen hatten, daher konnte ich einfach einen neuen mit fdisk erzeugen, welcher genau die gleichen Partitionen anlegte. Nochmal kurz an- und abstecken, Schwupps waren sie wieder da. Die Bootpartition war natürlich schon Hopps, da sie ganz vorne lag und recht klein war :(
Gut, die war ja eh “gebackupt” und vom Backup aus längst auf das neue Gerät gespielt.

Also können wir jetzt den Luksheader zurück schreiben:

sudo cryptsetup luksHeaderRestore --header-backup-file <file> <device>

Nachdem dies geklappt hat, können wir das Luksdevice öffnen:

sudo cryptsetup luksOpen <device> bla

Soweit war mir das ja noch alles bekannt, aber natürlich wurde das LVM auf dem LUKS Laufwerk von pvscan und co. nun auch nicht mehr gefunden. Somit durfte ich mich in die ganze LVM Sache einlesen .. juhu…
Innerlich hatte ich ja gehofft, dass der Secure Erase so langsam ist, dass er den LVM Teil noch nicht erreicht hat.
Natürlich hab ich KEIN Backup der LVM Metadaten .. und ich weiß auch nur noch grob wieviel MB da was hatte.

Nach längerem googeln fand ich heraus, dass die meisten Distris unter /etc/lvm/backup und /etc/lvm/archive immer mal wieder Metadaten von LVMs speichern bzw. “backupen”. Natürlich überall an jedem PC (an dem die HDD mit dem LVM mal steckte) gesucht, nirgendwo auf Anhieb etwas gefunden.
An dem Zweitpc, der damals nach dem Ausfall der SSD (welche die HDD ersetzt hat zur Überbrückung) das LVM auf der HDD erzeugt hat fand ich in /etc/lvm/archive aber dann doch 2,3 Backupfiles der Metadaten des gesuchten LVMs. Leider fehlte in den Backupfiles ein logisches Volume, weil LVM wohl immer nur vor den Befehlen ein Backup anlegt (warum auch immer), weswegen ein Backup nach dem letzten Befehl (der das letzte logische Volume anlegte) fehlt. Wie diese Dateien aussehen sieht man z.B. hier.
Es gibt ja auch so einen Befehl, mit dem man angeblich diese Daten aus dem LVM extrahieren kann:

dd if=/dev/xyz bs=512 count=255 skip=1 of=/tmp/blubb.txt

Trotz richtiger Ausführung und korrekter Partitionen war bei mir da nur Datenmüll drin (auch in den Datenmüll war nirgends eine Konfig zu sehen). Geht das nur mit LVM1?.

Zum Glück konnte ich das letzte logische Volume von Hand in die Datei einfügen, die ID ist egal, sie muss nicht die originale sein. Die Extends konnte ich ausrechnen: “pe_count” des bzw. aller physikalischen Volume(s) (pv) – extent_count jedes logischen Volumes(lv) = extent_count des fehlenden logischen Volumes. Dabei ist die 0 von “”pv0″, 0” immer die extent_count Zahl des vorigen Volumes. Ich muss dazu sagen: Ich hatte aber nur ein physikalisches Volume im LVM drin, deswegen war es so einfach.

Also “recovern” wir jetzt das LVM:

Zuerst das physikalische Volume … wie das geht, sagt uns tldp.org:

sudo pvcreate --uuid "some_long_string" --restorefile blubb.txt <PhysicalVolume>

Hierbei muss die uuid aber in der Backupdatei blubb.txt (für das pv) vorkommen, sonst gibts Fehlermeldungen oder Abstürze*.

Jetzt ist die VolumeGroup (und damit die logischen Volumes) dran:

sudo vgcfgrestore -f blubb.txt VolGroup01

Auch hier wieder: VolGroup01 muss in der blubb.txt vorkommen, sonst gibt es Fehler oder Abstürze*.

Ein Wunder … es hat gepklappt :D
Jetzt noch einmal folgendes:

sudo pvscan
sudo vgscan
sudo vgchange -ay VolGroup01

Parititonen mounten:

sudo mount /dev/mapper/VolGroup01-bla1 /mnt/bla1
sudo mount /dev/mapper/VolGroup01-bla2 /mnt/bla2
...

Sobald sowas wie ein “Sie müssen den Dateisystemtyp angeben” kommt ist die Partition bzw. das Dateisystem auf dem logischen Volume hinüber .. eine der ersteren hatte der Secure Erase leider schon erwischt, der Rest war aber vollständig vorhanden. Ich konnte also die gewünschten Daten retten und rauskopieren.
Ob man das kaputte Dateisystem auf dem vorderen logischen Volume auch wiederherstellen könnte weiß ich nicht, mit extundelete hätte man bestimmt einige der Dateien wiederherstellen können, …, für mich war das aber erstmal nicht wichtig, die Daten, die ich wollte, waren ja da. Super! Das hätte ich so nicht erwartet. :)

Das hier soll nur ein kleiner Bericht sein, der keinerlei Anspruch auf Vollständigkeit und Korrektheit erhebt, ich wollte euch nur erzählen, wie meine Datenrettung in der Realität abgelaufen ist. Es ging hier nur um ein paar wenige Dateien, welche zwischen dem letzten Backup und dem Tag des versehentlichen Erases lagen. Bei dem Ausfall meiner SSD (den die HDD ersetzt hat), war dies nicht mehr möglich, was ärgerlich war, da das Backup weiter zurück lag, allerdings gab es damals keine wichtigen Daten welche nur auf der SSD lagen. Ein weitere Vorteil war auch, dass ein großer Teil der betroffenen Daten sowieso in der Dropbox lagen.

Daher ein abschließender Rat: immer regelmäßig ein Backup erstellen. Wenn ihr es schon regelmäßig macht, macht es in noch kürzeren Abständen (und benutzt sowas wie Dropbox).

Mir ist übrigens durchaus bewusst dass Ausdrücke wie “das LVM” totaler Schwachsinn sind, daher entschuldige ich mich gleich dafür, hat sich halt so eingebürgert ;)

*= Ich bin erstaunt das solche elementaren Tools einfach abstürzen sobald in den Backupdateien die PVs bzw. LVs nicht gefunden werden. Eigentlich sollte das nicht passieren.

Quellen:
softpanorama.org linuxjournal.com formann.de linux.about.com tldp.org techrepublic.com extundelete.sourceforge.net thomas-krenn.com linux.die.net linuxquestions.org linuxjournal.com

Comments (0)

› No comments yet.

Leave a Reply

Allowed Tags - You may use these HTML tags and attributes in your comment.

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>