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

Du hast Probleme mit Deinem eMail-Programm, Webbrowser oder Textprogramm? Dein Lieblingsprogramm streikt?
Antworten
Benutzeravatar
manes
Beiträge: 941
Registriert: 27.08.2007 11:26:54
Wohnort: Köln
Kontaktdaten:

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

Beitrag von manes » 08.06.2011 12:19:56

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
Zuletzt geändert von manes am 12.06.2011 21:21:48, insgesamt 1-mal geändert.

Benutzeravatar
minimike
Beiträge: 5572
Registriert: 26.03.2003 02:21:19
Lizenz eigener Beiträge: neue BSD Lizenz
Wohnort: Köln
Kontaktdaten:

Re: Partitionstabelle zerschossen - schlechtes Beispiel

Beitrag von minimike » 08.06.2011 12:38:26

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

mklabel gpt
"Lennart Poettering is one of those typical IT leaders..." "like Linus Torvalds and Theo de Raadt?" "more like Bozo the Clown"
I am an Veteran Unix Admin. Don't hesitate about to support Devuan. See https://devuan.org/ for more details.

Benutzeravatar
manes
Beiträge: 941
Registriert: 27.08.2007 11:26:54
Wohnort: Köln
Kontaktdaten:

Re: Partitionstabelle zerschossen - schlechtes Beispiel

Beitrag von manes » 08.06.2011 13:34:24

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

Benutzeravatar
Huck Fin
Beiträge: 1024
Registriert: 10.03.2008 17:10:30

Re: Partitionstabelle zerschossen - schlechtes Beispiel

Beitrag von Huck Fin » 08.06.2011 16:25:14

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.

Benutzeravatar
manes
Beiträge: 941
Registriert: 27.08.2007 11:26:54
Wohnort: Köln
Kontaktdaten:

Re: Partitionstabelle zerschossen - schlechtes Beispiel

Beitrag von manes » 08.06.2011 22:58:30

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 :roll: .

schicksalergebene grüße
manes
Zuletzt geändert von manes am 09.06.2011 12:35:43, insgesamt 1-mal geändert.

Benutzeravatar
Soong
Beiträge: 207
Registriert: 09.05.2011 11:05:26
Lizenz eigener Beiträge: GNU Free Documentation License

Re: Partitionstabelle zerschossen - schlechtes Beispiel

Beitrag von Soong » 09.06.2011 09:03:28

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.
The strength of a civilization is not measured by its ability to fight wars, but rather by its ability to prevent them.
-Gene Roddenberry

Mitglied bei der Free Software Foundation oder der Free Software Foundation Europe werden oder kostenlos die Free Software Foundation Europe unterstützen!

Benutzeravatar
manes
Beiträge: 941
Registriert: 27.08.2007 11:26:54
Wohnort: Köln
Kontaktdaten:

Re: Partitionstabelle zerschossen - schlechtes Beispiel

Beitrag von manes » 12.06.2011 21:18:58

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

Antworten