ubuntuusers.de

Servus zusammen,

ich habe hier einen Murphy in Reinkultur ☹

Ich habe einen Rechner mit 2 HDs

 /dev/sda verschlüsseltes Ubuntu und Truecrypt - Partition
 /dev/sdb verschlüsselte Windowsinstallation ebenfalls mit einer Truecrypt - Partition

mit einer neuen SSD ausgerüstet und habe während der Installation von Quantal offensichtlich die beiden vorhandenen Platten gecleant [Mir ist unverständlich wie, als der Installer anzeigte, dass er statt der vorgesehenen /dev/sdc lieber /dev/sda als erste freie Platte nutzen wollte, brach ich ab und startete mit abgezogenen HDs die Installation nochmal]. Anyway, beide Platten sind nun laut GParted leer.

Die Truecrypt- Partitionen sind meine Datenlager, in der Partition auf /sdb habe ich gearbeitet, in der Partition auf /sda den Inhalt synchronisiert. Ich habe zuerst nur festgestellt, dass /sda beschädigt ist, da ich als erstes meine Ubuntu- Einstellungen von /sda nach /sdc kopieren wollte.

Vermeintlich mit /sdb als Backup ausgestattet, habe ich testdisk direkt auf /sda losgelassen. Leider wurde meine Partitionsstruktur nicht korrekt erkannt. Suchte ich nach Intel - Partitionen, wurden einige Fehler (Größenangaben) angezeigt und nur eine 2,5 MB große LUKS - Partition angezeigt, die natürlich nicht zu öffnen ist. Ein Durchlauf mit dem Partitionstyp "None" brachte meine korrekte Struktur, diese ließ sich aber nicht schreiben (kein Schreiben bei der Suche nach "none" verfügbar). Suchte ich nach Intel - Partitionen, erhielt ich nur Müll, auch mit der vertieften Suche ("deeper search").

Ich habe den Verlust der Ubuntu - Einstellungen als Lehrgeld abgehakt und wollte mein Backup von /sdc nach /sdb kopieren, und hier kam der Schock dergestalt, dass /sdc ebenfalls leer ist.

Ich habe nun als erstes eine Kopie von /sdc auf ein gesondertes Medium angestoßen, um testdisk dann auf das Image ansetzen zu können...

1

sudo dd if=/dev/sdc of=/externe_hd/500gbhd.img

Die meisten Ansätze aus der (:Datenrettung:) scheitern daran, dass die Platte verschlüsselt ist.

Was kann bei der Installation passiert sein? Wurden nur die Partitionen gelöscht oder ist hier mehr passiert? (Je mehr ich weiß, desto genauer kann ich ggf. im testdisk - Forum anfragen.

Was würdet ihr hier vorschlagen?

PS. Dass ich mir hier einen verdammten Bock geschossen habe, weiß ich selbst. Und ja, man sollte nicht installieren, wenn die Platten noch angesteuert werden. Und wieder ja, ich hätte auch die 150 GB regelmäßig nicht nur auf die andere HD im Server spiegeln, sondern auf DVD brennen können. Habe ich aber nicht und stehe deshalb jetzt dumm da 😉

Hallo,

Falls nur die Partition gelöscht wurde besteht noch Hoffnung. Habe selber sowas schonmal Repariert. Ich habe mit fdisk einfach eine neue Partion angelegt weil ich noch wusste wo sie anfängt und anfhört. Ich würde an deiner Stelle mal nach dem LuksHeader suchen im device (backup nicht vergessen).

Siehe dazu hier:

http://debianforum.de/forum/viewtopic.php?f=29&t=135268

PS: Falls der LuksHeader gelöscht wurde oder du aus versehen die falsche Platte mit cryptsetup überschrieben hast dann wars das leider ☹

Raybuntu schrieb:

Hallo,

Hi ☺

Falls nur die Partition gelöscht wurde besteht noch Hoffnung. Habe selber sowas schonmal Repariert. Ich habe mit fdisk einfach eine neue Partion angelegt weil ich noch wusste wo sie anfängt und anfhört. Ich würde an deiner Stelle mal nach dem LuksHeader suchen im device (backup nicht vergessen).

Siehe dazu hier:

http://debianforum.de/forum/viewtopic.php?f=29&t=135268

Das habe ich schonmal genau nach diesem Posting durchgeführt. Leider konnte ich nur eine LUKS - Partition wiederherstellen, die 2,5MB groß war und sich nicht öffnen ließ.

PS: Falls der LuksHeader gelöscht wurde oder du aus versehen die falsche Platte mit cryptsetup überschrieben hast dann wars das leider ☹

Die Platte ist -sicher- nicht überschrieben. Ich gehe davon aus, dass nur die Partitionen gelöscht wurden, aber die Wiederherstellung schlug bisher fehl (s.o.), weshalb ich auf die Idee gekommen bin, dass noch mehr passiert sein könnte...

Danke für die Antwort! ☺

Bist Du Dir bewusst, das eine Trucrypt - Partition in fehlerfreiem Zustand von gparted als unformatierter Datenträger dargestellt wird.

Ich entnehme deinen Worten, das die Windows-Partition mit Systemverschlüsselung war.

Daher halte ich es für möglich, das die Daten rettbar sind.

Sind meine Ahnungen richtig?

Andre

PS versuche doch mal von der Life-cd zu booten, truecrypt zu installieren und dann die truecrypt-Partitionen zu mounten. Eventuell hast du glück.

agschaal schrieb:

Bist Du Dir bewusst, das eine Trucrypt - Partition in fehlerfreiem Zustand von gparted als unformatierter Datenträger dargestellt wird.

Ja ☺

Bisher wurde neben der Windowsinstallation die zweite Truecrypt - Partition gesondert angezeigt, das ist jetzt nicht mehr der Fall.

Ich entnehme deinen Worten, das die Windows-Partition mit Systemverschlüsselung war.

Korrekt ☺ Aber nur die Partition, nicht die gesamte Platte, sodass ich unter gparted bislang -immer- die Partitionen sehen konnte.

Daher halte ich es für möglich, das die Daten rettbar sind.

Sind meine Ahnungen richtig?

Andre

PS versuche doch mal von der Life-cd zu booten, truecrypt zu installieren und dann die truecrypt-Partitionen zu mounten. Eventuell hast du glück.

Ich habe jetzt neu ja auf /sdc ein laufendes Ubuntu mit installiertem Truecrypt. Der Mountvorgang des -inhaltsgleichen- Truecrypt- Containers von /sda oder /sdb schlägt halt fehl, weil offenbar die Partitionen gelöscht wurden... /sda habe ich bereits versaubeutelt, /sdb wird gerade in ein Image geschrieben um es mit Testdisk zu bearbeiten...

Danke soweit! Micha ☺

Hallo gnomicha,

ich beneide Dich nicht um die Suppe, die Du Dir von Murphy zum Auslöffeln bestellt hast...

Alles, was ich jetzt schreibe, ist ganz grober theoretischer Natur, weil ich keine Erfahrungen mit der Truecrypt-Geschichte geschweige denn deren Details im Hintergrund habe.

Wenn ich Dich recht verstehe und die Informationen ("früher wurde von gparted die Truecrypt-Partition angezeigt") richtig interpretiere, dann ist Dir die Partitionstabelle abhanden gekommen. Wenn Du also die Partitionstabelle rekonstruieren könntest, dann müsstest Du wieder auf die Partition zugreifen können. Richtig? Das setzt natürlich voraus, dass nur der MBR gelöscht wurde. Wenn tatsächlich Teile der verschlüsselten Partition überschrieben wurden, würde ich aus dem Bauch heraus sagen, dass eine Rettung der Daten unwahrscheinlich ist, weil möglicherweise wichtige Informationen der (verschlüsselten) Datenorganisation respektive des Dateisystem fehlen. Wohlgemerkt: Einschätzung aus dem Bauch heraus und keine nennenswerte Erfahrung.

Was kann bei der Installation passiert sein? Wurden nur die Partitionen gelöscht oder ist hier mehr passiert?

Das sind gute Fragen! Ich würde diesen Fragen nachgehen.

Eine Möglichkeit: Du könntest versuchen, das Szenario in einem Testsystem (z.B. VM) mit gleicher Systemkonfiguration nachzubilden. Wie müsste die Partitionstabelle demnach ausgesehen haben? Vielleicht kannst Du im "Sandkasten" feststellen, was bei Deinem Vorgehen schiefglaufen ist und welche Veränderungen am System und an den Platten passieren (z.B. über einen Vergleich der Festplattenimages vorher - nachher). Welche Informationen/Datenbereiche müsstest Du zurückspielen, um wieder Zugriff zu bekommen? Wie fehlertolerant ist das? Kannst Du auch von einem Rettungssystem unter bestimmten Umständen wieder darauf zugreifen? Wie geht das?

Danach könntest Du Dich direkt an Deinem Image versuchen und ggf per Trial and Error / Bruteforce die unbekannten und fehlenden Partitionstabelleninformationen austesten.

Grundsätzlich - aber das weißt Du gerade eben wahrscheinlich selbst am Besten - ist der Zeitpunkt schmerzhaft und (deshalb) günstig, die bisherige Backupstragie zu überdenken. Murphy hat Dir die Schwachstellen Deinens Systems aufgezeigt...

Möge die Macht mit Dir sein!

Vito

Vito Leone schrieb:

Hallo gnomicha,

Hi ☺

ich beneide Dich nicht um die Suppe, die Du Dir von Murphy zum Auslöffeln bestellt hast...

Ich schlucke noch...

Alles, was ich jetzt schreibe, ist ganz grober theoretischer Natur, weil ich keine Erfahrungen mit der Truecrypt-Geschichte geschweige denn deren Details im Hintergrund habe.

Wenn ich Dich recht verstehe und die Informationen ("früher wurde von gparted die Truecrypt-Partition angezeigt") richtig interpretiere, dann ist Dir die Partitionstabelle abhanden gekommen. Wenn Du also die Partitionstabelle rekonstruieren könntest, dann müsstest Du wieder auf die Partition zugreifen können. Richtig? Das setzt natürlich voraus, dass nur der MBR gelöscht wurde. Wenn tatsächlich Teile der verschlüsselten Partition überschrieben wurden, würde ich aus dem Bauch heraus sagen, dass eine Rettung der Daten unwahrscheinlich ist, weil möglicherweise wichtige Informationen der (verschlüsselten) Datenorganisation respektive des Dateisystem fehlen. Wohlgemerkt: Einschätzung aus dem Bauch heraus und keine nennenswerte Erfahrung.

Was kann bei der Installation passiert sein? Wurden nur die Partitionen gelöscht oder ist hier mehr passiert?

Ich gehe davon aus, das nur die Partitionstabelle gelöscht wurde. Vom Ablauf her ging es so, dass ich im Installationsdialog von Quantal bei der Festplattenauswahl die drei Häkchen von oben nach unten setzte (1. Ganze Platte verwenden, 2. Verschlüsseln. 3. LVM nutzen) und dann mit der Option "Etwas anderes" zu checken, welche Festplatte hier genutzt werden sollte, um nicht auf "weiter" zu klicken und auf eine ungewünschte Festplatte zu installieren. [Eigentlich fragt der Installer immer, ob "folgende Änderungen ..." auf die Festplatte geschrieben werden sollen, aber darauf wollte ich nicht setzen. Fand mich schon vorsichtig ☹ ] Als ich dann unter "Etwas anderes" sah, dass er /sda nutzen wollte, habe ich abgebrochen und -mit abgezogenen /sda und /sdb- neu gestartet. Trotzdem sind beide Platten erstaunlich leer (siehe unten Update), obwohl die Zeitspanne von maximal 20 Sekunden im Menü nicht für das Überschreiben von mehreren GByte reichen konnte. UND auch noch /sdb, welches der Installer gar nicht bespielen wollte, leer ist.

Das sind gute Fragen! Ich würde diesen Fragen nachgehen.

Siehe unten: Ich werde nach vergleichbaren Fehlern im Forum bei "Installation" suchen.

Eine Möglichkeit: Du könntest versuchen, das Szenario in einem Testsystem (z.B. VM) mit gleicher Systemkonfiguration nachzubilden. Wie müsste die Partitionstabelle demnach ausgesehen haben? Vielleicht kannst Du im "Sandkasten" feststellen, was bei Deinem Vorgehen schiefglaufen ist und welche Veränderungen am System und an den Platten passieren (z.B. über einen Vergleich der Festplattenimages vorher - nachher). Welche Informationen/Datenbereiche müsstest Du zurückspielen, um wieder Zugriff zu bekommen? Wie fehlertolerant ist das? Kannst Du auch von einem Rettungssystem unter bestimmten Umständen wieder darauf zugreifen? Wie geht das?

Danach könntest Du Dich direkt an Deinem Image versuchen und ggf per Trial and Error / Bruteforce die unbekannten und fehlenden Partitionstabelleninformationen austesten.

Bräuchte erst noch neue Hardware (Stand 2007). Datenretter könnte günstiger sein, mal sehen 😉

Grundsätzlich - aber das weißt Du gerade eben wahrscheinlich selbst am Besten - ist der Zeitpunkt schmerzhaft und (deshalb) günstig, die bisherige Backupstragie zu überdenken. Murphy hat Dir die Schwachstellen Deinens Systems aufgezeigt...

Recht hast Du! und

Möge die Macht mit Dir sein! Vito

Danke!

UPDATE: Ein nächtlicher Scan meines Images von /sdb mit Testdisk (Partitionstyp Intel, deep search) erbrachte nichts, nicht mal Fehler. Scanne grad nochmal mit (Partitionstyp None). Werde noch weiter im Bereich "Installation" Beiträge finden, ob sich ähnliche Fehler finden lassen. Habe im Testdisk- Forum gepostet, falls ich mit meinen Sucheinstellungen verkehrt liegen sollte. Beitrag ist noch nicht sichtbar aufgrund Moderationsvorbehalt.

Wie gesagt, ich war in der selben Situation und Testdisk konnte auch nichts finden. Du hast doch ein image der Platte gezogen? Ich würde mit dem Image mal versuchen die Partions Tabelle manuell wieder herzustellen mit fdisk. Suche dir vorher den LuksHeader nach der Methode des Debian Forumeintrags das ich dir geschickt habe.

1
2

sudo losetup /dev/loop0 /pfad/zum/image.img
sudo fdisk /dev/loop0

Bei mir hatte es geklappt weil ich noch ungefähr wusste wie groß die Partition ist.

Btw.: Nur mit dem Backup spielen!

Raybuntu schrieb:

Wie gesagt, ich war in der selben Situation und Testdisk konnte auch nichts finden. Du hast doch ein image der Platte gezogen? Ich würde mit dem Image mal versuchen die Partions Tabelle manuell wieder herzustellen mit fdisk. Suche dir vorher den LuksHeader nach der Methode des Debian Forumeintrags das ich dir geschickt habe.

1 2	sudo losetup /dev/loop0 /pfad/zum/image.img sudo fdisk /dev/loop0

Bei mir hatte es geklappt weil ich noch ungefähr wusste wie groß die Partition ist.

Btw.: Nur mit dem Backup spielen!

Hi! Im Moment läuft noch Testdisk in den erdenklichen Varianten durch, damit ich nichts übersehe. Danach würde ich die Variante mit fdisk probieren, nur dass ich statt nach der LUKS - Signatur nach einer Truecrypt- Signatur suchen muss. Habe mich vllt. etwas umständlich ausgedrückt im ersten Posting 😉 Die Größe der Partition weiß ich zum Glück auch noch, 349 GB. Bevor ich das manuell mache, werde ich unter einem LiveWindows das im Testdisk - Forum empfohlene Tool TestCrypt http://sourceforge.net/projects/testcrypt/?source=dlp ausprobieren. Höchste Priorität hat die Truecrypt - Partition auf /sdb, meinem alten Windowslaufwerk.

Verständnisfrage: Ich habe grad gesehen, dass man mit Testdisk ein Image der Partition erstellen kann. Ich habe ganz stumpf ein Image mit dd gezogen, siehe erster Post. Extra nicht dd_rescue, weil ich keine lesbaren Daten im verschlüsselten Bereich habe. Ist das jetzt falsch?

Nein. Mit dd solltest du auf der sicheren Seite sein.

EDIT: Falls du nur erstmal an den Daten intressiert bist kannst du versuchen (falls du weißt wo dein Truecrypt Header liegt) mit losetup und offset zu arbeiten. Ich kenne mich mit Truecrypt nicht so aus. Aber bei cryptsetup war es möglich das device dann zu unlocken. Dadurch hast du dann keine Partitionstabelle aber das entschüsseln der Daten sollte dann gehen. Danach würde ich von den Entschlüsselten Daten ein disk dump (dd) machen und darin dann nach Dateisystemen suchen.

http://bochs.sourceforge.net/doc/docbook/user/loop-device-usage.html

gnomicha schrieb:

Servus zusammen,

Die meisten Ansätze aus der (:Datenrettung:) scheitern daran, dass die Platte verschlüsselt ist.

Deswegen Rede ich seid Ewigkeiten, das man den mist nicht machen sollte.

Außer, das man immer wieder ärger damit hat (windows und Linux) habe ich den sinn dessen nicht verstanden.

Auch bei Android gibts diesen mist..hatte das mal aus versehen eingestellt, bei einer Einrichtung am tablet. Anschliessend lief das zäh wie Kaugummi.

Wichtige Private Daten liegen bei mir auf 2 USB Stick..einer liegt verschlossen im Schrank und der andere hängt am Schlüsselbund...den ich bisher zuletzt als Kind verloren habe.

Frank62 schrieb:

Deswegen Rede ich seid Ewigkeiten, das man den mist nicht machen sollte.

Außer, das man immer wieder ärger damit hat (windows und Linux) habe ich den sinn dessen nicht verstanden.

Auch bei Android gibts diesen mist..hatte das mal aus versehen eingestellt, bei einer Einrichtung am tablet. Anschliessend lief das zäh wie Kaugummi.

Wichtige Private Daten liegen bei mir auf 2 USB Stick..einer liegt verschlossen im Schrank und der andere hängt am Schlüsselbund...den ich bisher zuletzt als Kind verloren habe.

Das scheint für dich zwar Mist zu sein ist jedoch für einige Menschen wichtig. Es gibt Daten die man vor Diebstahl schützen möchte oder muss (Firmen Daten). Gerade wenn man seinen Laptop oft irgendwohin mitnehmen muss ist die Gefahr groß.

Raybuntu schrieb:

Gerade wenn man seinen Laptop oft irgendwohin mitnehmen muss ist die Gefahr groß.

Deswegen hängen die Wichtigen Daten am Schlüsselbund und der ist mit Kette am Hosengürtel...selbst wenn dir der Läppi im Straßencafe aus der Hand oder vom Tisch gerissen wird hängt der USB Stick an der Hose.

Frank62 schrieb:

Deswegen hängen die Wichtigen Daten am Schlüsselbund und der ist mit Kette am Hosengürtel...selbst wenn dir der Läppi im Straßencafe aus der Hand oder vom Tisch gerissen wird hängt der USB Stick an der Hose.

Und die Kopien von sensiblen Daten liegen dann zum Beispiel in Form von temporären Dateien frei zugänglich auf dem unverschlüsselten System. Das ist jetzt nicht Dein Ernst, oder?

Meiner Meinung ist eine Lehre des konkreten Falls, dass man ein funktionierendes(!) Backup seiner Daten haben sollte. Womit dann auch ich hier mein Mantra untergebracht hätte 😉

Die Diskussion geht aber am eigentlichen Thema der Datenrettung vorbei.

Vito

nein, aber truecrypt lässt sich auch auf usb-platten installieren und dann mit luckybackup aktuell halten.

Andre