[gelöst] verschlüsseltes LVM Partitionstabelle zerstört

[manes]

Liebes Forum,
je nach Laune hätte der Betreff auch: "Partitionstabelle zerschossen - gutes Beispiel" heißen können.

wenn man am System herumschraubt, sollte man seine Sinne beisammen haben! Wer in Eile oder mit den Gedanken schon mit etwas anderen beschäftigt am Filesystem oder an der Partitionierung fummelt, zahlt fast immer einen hohen Preis.

Ohne ernsthaften Gedanken, daß meine Daten noch zu retten sind[siehe unten], hier nur kurz die Moritat von der kaputten Partitionstabelle:

Hier hatte ich von meinem Problem mit der Festplatte >2TB erzählt, die in einem älteren externen Gehäuse nicht zu partitionieren war.
Habe bei Atelco dieses angeblich bis 3TB vertragende Gehäuse namens Wintech EX-MOB-90 - 3,5" USB 3.0 gefunden und habe dann schnell schnell vorm Sport die neue Festplatte ins Gehäuse geschoben, parted gestartet und den mbr mit einer gpt überschrieben - allerdings auf der Festplatte meines Notebooks, nicht auf der externen Platte.
testdisk findet nur noch eine funktionierende Partition der Größe, die ich parted aufgetragen hatte (nachdem

Code: Alles auswählen

mkpart primary 0 3000g

mit der Meldung, daß die Platte eine geringere physikalische Größe habe, habe ich das mehrfach mit geringeren Partitionsgrößen versucht und hatte letztlich "Erfolg").
Also, liebe Kinder:
Bei Arbeiten am System IMMER jeden Schritt genau bedenken, vorher von allen wichtigen Daten (Partitionstabellen, luks-Header...) backups machen und sowas NIE NIE NIE unter Zeitdruck machen.

Grüße
manes

PS: Ich hatte eine boot-Partition sda1 nicht erinnerlicher Größe und ein verschlüsseltes LV mit allen anderen Partitionen auf sda2. Jetzt ist so eine gpt ja viel größer und schreibt sich auch noch an beide Enden der Festplatte. Eine Frage habe ich: besteht eine realistische Chance, den Beginn des LV bzw den Header des luks-Containers aufzuspüren und so wenigstens noch meine Daten wiederherzustellen?
Merci im Vorabbereich!

manes

edit: typos

[minimike]

Bei Partitionen ab 2 TB sollten gleich MsDOS Partitionstabellen mittels GPT abgelöst werden

mklabel gpt

[manes]

hi darko,
ja äh, "sollten"? über den mbr können nur 2^32x512byte = ~2,2TB adressiert werden. den teil mit parted /dev/sdb und mklabel gpt hatte ich in der moritat weggelassen...

manes

[Huck Fin]

Testdisk findet sonst nichts ?

Ich habe mir -nach mehreren Supergaus- angewöhnt, alle Daten auf einer zweiten Festplatte zu sichern.
Alles Wichtige existiert sogar dreifach.

Wichtig wär bei dir erst mal die Platte zu klonen und am Klon die verschiedenen Test's durchzuführen.

[manes]

update offtopic:
entgegen dem versprechen auf der verpackung "für festplatten bis 3tb" kommt das "Wintech EX-MOB-90 - 3,5" USB 3.0" nicht mit der hitachi 7k3000 zurecht und kann nur 802GB adressieren.

allerdings konnte der händler meines vertrauens helfen. die ICY BOX IB-390StUS-B kommt mit eSata und leider nur usb2.0 daher, schleift aber immerhin die smart-meldungen durch und kann auch mit 3tb umgehen.

@huck: mmmh, ja. meinen letzten datengau hatte ich 2004 mit w2k und einemr verschlüsselten backup festplatte ohne schlüssel. seitdem backups. meine zwei backupplatten waren schon eine weile an der kapazitätsgrenze, deshalb die aufrüstung... heute bin ich nicht mehr streßtolerant, daher kopiere ich nur die backups auf die neuen platten und widme mich später wieder der wiederherstellung meiner daten und der kaputtgemachten partition. und ja, die platte werde ich klonen.

für tips auch jenseits von testdisk bin ich übrigens aufgeschlossen .

schicksalergebene grüße
manes

[Soong]

Die c't hatte da vor einiger Zeit einen Artikel zur Datenrettung. Da stehen noch ein paar weitere Tipps drin. Leider kann ich dir den Artikel nicht zukommen lassen oder ihn hier wiedergeben, aber vielleicht hilft es dir ja wenn ich dir sage, dass dort neben testdisk auch noch foremost und gpart erwähnt werden und was sie tun.

[manes]

vielen dank für eure hinweise!
mein problem ist gelöst, die daten überwiegend geborgen. dank an julia für die unterstützung (das war jetzt privat) und wieder mal an danielx für den hinweis in diesem thread, wie man den luks-header findet.

nochmal in kurz: die interne festplatte meines notebooks, bootpartition sda1, sda2 als dm-crypt-verschlüsseltes lvm mit den übrigen partitionen.
mbr und partitionstabelle versehentlich mit gpt überschrieben.

testdisk und foremost finden auf dem verschlüsselten device natürlich nichts. gpart wirft auch keinen brauchbaren output aus und findet nur die nutzlose gpt.
der luksheader von sda2 sollte aber unbeschädigt geblieben sein. mit

Code: Alles auswählen

hexdump -C /dev/hdd | grep "4c 55 4b 53 ba be"

ist er zu finden:

Code: Alles auswählen

0f32be00  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00  |LUKS....aes.....|

den ersten wert von hexadezimal zu dezimal umrechnen, das ist also

Code: Alles auswählen

[hex]0f32be00  -> [dez]254983680

das ist also der anfang der lukspartition. ich lege ein loop-device an, das am anfang der lukspartition beginnt:

Code: Alles auswählen

losetup -o 254983680 /dev/loop5 /dev/sda2

ist das auch tatsächlich der anfang der lukspartition? mache ein

Code: Alles auswählen

cryptsetup isLuks /dev/loop5

unixtypisch keine meldung, wenn alles ok ist.
nun das luksdevice entschlüsseln, nach

Code: Alles auswählen

cryptsetup luksOpen /dev/loop5 bla

die passphrase eingeben.

jetzt führt der versuch, /dev/mapper/bla zu mounten, zur fehlermeldung

Code: Alles auswählen

mount: unbekannter Dateisystemtyp „LVM2_member“

das liegt daran, daß -zumindest in meinem setting- mehrere partitionen/logical volumes auf dem lv liegen. bei mir sind das root, home und swap:

Code: Alles auswählen

lvs
LV   VG    Attr   LSize   Origin Snap%  Move Log Copy%  Convert
home <volume-group> -wi-ao 213,09g                                      
root <volume-group> -wi-ao  13,97g                                      
swap <volume-group> -wi-a-   5,59g    

die volumegroup aktivieren (wozu auch immer das nötig ist?):

Code: Alles auswählen

vgchange -ay <volume-group>

und jetzt kann ich die einzelnen partitionen mounten:

Code: Alles auswählen

mount /dev/<volume-group>/<logical-volume> -o ro,user

bei mir ist das: mount /dev/t400s/home -o ro,user.

et voilà, ich kann wieder auf meine daten zugreifen. weil gpt aber eine kopie an das ende der platte kopiert hat, wird womöglich die eine oder andere datei beschädigt sein, wenn irgendwas genau am ende gelegen hat.

noch einmal großen dank an danielx.

viele grüße
manes