Hallo!

Ich habe ein dickes Problem:

Für Testzwecke habe ich Win7 auf meine Systemplatte installiert. Diese Installation hat allerdings ohne zu fragen die 100MB Boot-Partition auf mein vollverschlüsseltes RAID-5 gelegt. Jetzt kann ich es natürlich nicht mehr öffnen. Glücklicherweise(?) habe ich den luks-Header damals weggesichtert.

Was muss ich machen, um ihn wieder auf /dev/sdb einzuspielen?

Sollte / muss ich die Windowspartition vorher löschen? Auf welchem weg? Einfach wie gparted weglöschen?

Wird es dann wieder funktionieren (abgesehen von den zu erwartenden 100MB korrupten Daten am Laufwerksanfang)?

In leichter Panik und mit viel Dank im voraus !!

Hades

Dank des super Blogs von Raptor 2101 (http://blog.raptor2101.de/2010/05/27/luks-verschlusselte-platten-retten/)

habe ich den Header wieder eingespielt. cryptsetup luksOpen funktioniert nun wieder, nur mounten kann ich es noch nicht

sudo mount /dev/mapper/r5 /mnt/r5uncrypt
mount: Sie müssen den Dateisystemtyp angeben

Was will es mir sagen? Ich nehme mal an, das Filesystem (XFS) ist in Mitleidenschaft gezogen worden, schließlich hat Windows 100MB angelegt und mindestens 35MB vollgekritzelt,

Wie bekomme ich das wieder hin?

Vielen Dank!

sudo mount -t xfs /dev/mapper/r5 /mnt/r5uncrypt

Ansonsten bleibt dir nur Rettung ohne Dateinamen auf Blockebene per PhotoRec oder Backup verwenden. Weitestgehend Standardeinstellungen, aber im entschlüsselten Zustand.

Die Wiederherstellung kann dann nach Dateiinhalten durchsucht und mit weiteren, im Netz dokumentierten Scripten nachbearbeitet werden, um die Spreu vom Weizen zu trennen.

Bedenke, dass die Sicherung auf einen ebenfalls verschlüsselt eingebundenen Datenträger erfolgen sollte, um die Daten nicht unverschlüsselt auf Sektoren abzulegen. Dies ist teilweise nicht wieder löschbar, z.B. beim Sektorensterben sind ggf. Informationen später noch auslesbar. Nur verschlüsselt abspeichern.

Vielen Dank für den Beitrag!

Ich habe -txfs schon getestet und war erfolglos - was zu erwarten war.

Jetzt probiere ich gerade

xfs_rescue -n /dev/mapper/r5 

Ich hoffe das ist richtig. Zur Vorsicht habe ich mal -n für (keine Änderungen auf dem Filesystem) angegeben um nur mal zu schauen, ob er was fidnet. Der Superblock ist weg (war zu erwarten). Jetzt sucht er gerade nach einem 2. Superblock. Ich hoffe, das Filesystem ist so intelligent konstruiert, dass es den nicht in die Nähe vom ersten gelegt hat! Weiß das jemand wo der bei XFS liegt?

Das dauert jetzt schon ein paar Minuten. Wenn der immer an einem bestimmten Ort liegt, dann müssste das Programm den schon gefunden haben - na ja gut es weiß ja nicht, dass das gesamte Laufwerk zu dem FS gehört. Also sucht der jetzt die 4TB durch?

Ich bin noch nicht so weit das FS aufzugeben, vielleicht bekomme ich es ja wieder hin?

Das Ergebnis ist da:

Kandidat für zweiten Superblock gefunden...
zweiter Superblock geprüft...
Schreiben könnte primären Superblock verändern
Primärer Superblock könnte verändert worden sein.
Es kann nicht im no_modify.Modus fortgefahren werden.
Es wird nun beendet.

Sieht schon mal so aus, als würde der 2. Superblock nicht neben den 1. geschrieben werden.

Was nun? Einmal ohne Parameter laufen lassen? Oder gleich mit -L ?

Also fassen wir es kurz zusammen:

Du hast die ersten X-Blöcke deines FileSystems verloren. Den wichtigen Teil (CryptoHeader) konntest du wieder herstellen. Die halbe Miete hast du. Jetzt brauchen wie den XFS-Header (Superblock).

Machen wir es kurz und knapp: Das ist eine "alles oder nichts" Nummer. Ich weiß du hast ein backup suchst aber eine Datei die in einem zu alten Stand (oder gar nicht) im Backup ist. Wenn du den zweiten Superblock zum "primären" superblock machst, kannst du diese Datei verlieren. Ich würd vorher auf jeden fall mal photorec drüber laufen lassen und ggf deine Datei so retten.

Prinzipiell ist es aber vorgesehen vom primären auf den sekundären Superblock zu wechseln (laut manpage)

Dann ist der Superblock also doch sowas wie in NTFS die Kopie in der Mitte? Wird der denn auch immer mitgeführt mit Veränderungen an den Files? Das wäre natürlich der Hammer!

Vielen Dank!

Habe jetzt den Befehl ohne Parameter n laufen, das dauert natürlich wieder ein paar Stunden. Dann hoffe ich darauf, dass ich da was auswählen kann um den 2. In den Primärblock zu kopieren.

Weitere Daten sollten dabei doch auch nicht verloren gehen? So kann photore

später immernoch zur Rettung eingesetzt werden oder täusche ich mich?

unter umständen, mounte das filesystem auf jeden fall read only.. wobei mehr schaden als jetzt kannst ud eh nicht mehr anrichten...

Werde ich beachten!

Es was spät gestern und ich habe ab einer gewissen Uhrzeit alles in einen falschen Thread gepostet: http://forum.ubuntuusers.de/topic/xfs-formatiert-datenretten/ Da mir Raptor dort auch noch geantwortet hat, habe ich es auch nicht bemerkt ! Tut mir leid.

Zum Stand:

xfs_rescue ist durch und hat den 2. auf den 2. Superblock geschrieben. Mounten lässt sich das LW, ist aber leer und es gibt auch kein lost+found. Mit dem folgenden Mountbefehl klappt es überhauptnicht.

sudo mount -o sunit=256,swidth=2 /dev/mapper/r5 /mnt/r5uncrypt
mount: wrong fs type, bad option, bad superblock on /dev/mapper/r5,
       missing codepage or helper program, or other error
       Manchmal liefert das Syslog wertvolle Informationen – versuchen
       Sie  dmesg | tail  oder so

HadesVsPluto schrieb:

Es was spät gestern und ich habe ab einer gewissen Uhrzeit alles in einen falschen Thread gepostet: http://forum.ubuntuusers.de/topic/xfs-formatiert-datenretten/ Da mir Raptor dort auch noch geantwortet hat, habe ich es auch nicht bemerkt ! Tut mir leid.

deswegen postet man nur in einem thread

Ja, das war der Plan. Du meinst, man liest nur einen Thread gleichzeitig. In den anderen wollte ich gar nichts posten.

xfs_rescue ist durch und spuckte danach folgendes aus, was die Länge der Console sprengte, deshalb habe ich es nicht von Anfang an, kann mich aber daran erinnern, dass er den 2. Superblock in den 1. geschrieben hat und dann kam folgendes (was ich eben nich von Anfang an habe:

agi unlinked bucket 55 is 2638590924 in ag 0 (inode=2638590924)

    ...usw...

agi unlinked bucket 63 is 3495417566 in ag 0 (inode=3495417566)
sb_fdblocks 974699248, counted 96912
Wurzel-Inode-Stück nicht gefunden
Phase 3 - für jedes AG...
        - agi unverknüpfte Listen werden gescannt und bereinigt...
Fehler folgt ag 0 unverknüpfter Liste
        - bekannte Inodes werden behandelt und Inode-Entdeckung wird
durchgeführt...
        - agno = 0
bad magic number 0xf3bd on inode 128
bad version number 0x7c on inode 128
bad inode format in inode 128

    ...usw...

bad magic number 0xd1a8 on inode 191
bad version number 0x65 on inode 191
bad inode format in inode 191
bad magic number 0xf3bd on inode 128, magische Nummer wird zurückgesetzt
bad version number 0x7c on inode 128, Versionsnummer wird zurückgesetzt
bad inode format in inode 128
cleared root inode 128

    ...usw... 

bad magic number 0xd1a8 on inode 191, magische Nummer wird zurückgesetzt
bad version number 0x65 on inode 191, Versionsnummer wird zurückgesetzt
bad inode format in inode 191
cleared inode 191
        - agno = 1
        - agno = 2
        - agno = 3
        - neu entdeckte Inodes werden behandelt...
Phase 4 - auf doppelte Blöcke überprüfen...
        - Liste mit doppeltem Ausmaß wird eingerichtet...
Wurzel-Inode wurde verloren
        - es wird geprüft ob Inodes Blocks doppelt beanspruchen...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
Phase 5 - AG-Köpfe und Bäume werden erneut gebildet...
        - Superblock wird zurückgesetzt...
Phase 6 - Inode-Verbindbarkeit wird geprüft...
Wurzel-Verzeichnis wird neu initialisiert
Echtzeit-Bitmap-Inode wird neu initialisiert
Echtzeit-Zusammenfassung wird neu initialisiert
        - Inhalte der Echtzeit-Bitmaps und Zusammenfassungs-Inodes werden zurückgesetzt
        - Dateisystem wird durchquert ...
        - durchqueren beendet ...
        - nicht verbundene Inodes werden nach lost+found verschoben ...
Phase 7 - Verweisanzahl wird geprüft und berichtigt...
resetting inode 128 nlinks from 1 to 2
Beachten Sie - Stripe-Einheit (0) und -Beite (0) Felder wurden
zurückgesetzt. Bitte setzen Sie mit mount -o sunit=<Wert>,swidth=<Wert>
erledigt

Die letzte Meldung verstehe ich nicht. Was soll ich nun tun bzw. warum? Meint es, dass es aus der fstab rausgeflogen ist?

Eine kleine Chance besteht also noch.

Plan B, falls es nicht wie gewünscht funktioniert, mit Photorec lässt sich keine Verzeichnisstruktur aufrechterhalten zu können und auch keine Dateinamen (das sind wohl die fehlenden Informationen). Das ist problematisch, da es auch die Dateierweiterung .tex nicht kennt. Es wird schwierig meine Seminararbeit zu finden, die aus einer Reihe von jpg png tex ods bib -Dateien besteht, da ich die 4TB erstmal irgendwo hinschreiben muss und dann einzeln durchschauen muss, was vermutlich Monate dauern würde. Gibt es ein Programm, dass die Verzeichnisstruktur beachtet (falls noch da) oder Dateinamen oder zumindest die tex und ods Datei gefunden werden kann?

HadesVsPluto schrieb:

Beachten Sie - Stripe-Einheit (0) und -Beite (0) Felder wurden
zurückgesetzt. Bitte setzen Sie mit mount -o sunit=<Wert>,swidth=<Wert>
erledigt

Die letzte Meldung verstehe ich nicht. Was soll ich nun tun bzw. warum? Meint es, dass es aus der fstab rausgeflogen ist?

Wenn du dein XFS anlegst sollte man normalerweise sunit und swidth angeben um dem XFS mitzuteilen wie das unterlagerte RAID Device aufgebaut ist, damit es optimierungen beim WriteOut vornehmen kann. Wenn du keine RAID hast, kannst du das ignorieren. Anderfalls teilt dir xfs_repair mit, dass es diese Initialen werte gerade verloren hat und du dich manuell darum kümmern musst.

Plan B, falls es nicht wie gewünscht funktioniert, mit Photorec lässt sich keine Verzeichnisstruktur aufrechterhalten zu können und auch keine Dateinamen (das sind wohl die fehlenden Informationen). Das ist problematisch, da es auch die Dateierweiterung .tex nicht kennt. Es wird schwierig meine Seminararbeit zu finden, die aus einer Reihe von jpg png tex ods bib -Dateien besteht, da ich die 4TB erstmal irgendwo hinschreiben muss und dann einzeln durchschauen muss, was vermutlich Monate dauern würde. Gibt es ein Programm, dass die Verzeichnisstruktur beachtet (falls noch da) oder Dateinamen oder zumindest die tex und ods Datei gefunden werden kann?

wie im Thread steht O&O Recovery oder photorec