Frage an die Profis: Datenrettung aus Luks-Container

**Jack_Herer** · 10.01.17, 13:44

Hallo erstmal,

also ich hab folgendes Problem: ich habe vor ein paar Tagen endlich mein Win endgültig in die Wüste geschickt und deshalb das System neu aufgesetzt und zwar mit einer Mint 18.1 Cinnamon - bitte keine bösen Kommentare

- jedenfalls läuft alles so weit wunderbar, allerdings hab ich das Problem, daß ich seitdem nicht mehr auf die Partition zugreifen kann die auf meiner backup Platte in einem Luks-Container liegt.

Ich habe mal ein wenig recherchiert und heraus gefunden daß es in Luks-Containern häufiger vorkommt (http://unix.stackexchange.com/questi...usb-flashdrive) daß es Probleme mit den journals in einer ext4 Partition gibt. Ich vermute mal daß das hier dasselbe ist, weil an der Platte selbst habe ich gar nichts gemacht. Ist ja meine backup Platte, alle system relevanten Dingelchen sind über die interne HD gelaufen.

Ich poste mal das Ergebnis vom mount-versuch:

Code:

MainMachine ~ # cryptsetup luksOpen /dev/sdb3 crypt_sdb3
Enter passphrase for /dev/sdb3:
MainMachine ~ # mount /dev/mapper/crypt_sdb3 /media/tmp
mount: wrong fs type, bad option, bad superblock on /dev/mapper/crypt_sdb3,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
MainMachine ~ #

Gut ... ich hab also jetzt mal ein discdump gestartet um die Daten aus dem Luks-Container auf eine andere 'native' ext4 Partition zu überspielen.
Das kleine Problem daß die Partition 500GB groß ist und ich auf der restlichen Platte nicht mehr so viel Platz zur Verfügung habe, hab ich - hoffentlich - mit count=xxx übergangen. Die Partition enthält auch keine 500GB Daten, und es dreht sich grad mal um 30 GB oder so Differenz.

Code:

MainMachine ~ # dd if=/dev/mapper/crypt_sdb3 of=/dev/sdb1 bs=2K count=228026880

Jetzt meine laienhafte Frage: Hab ich soweit alles richtig gemacht? Wie geh ich jetzt weiter vor um die Partition wieder herzustellen? mit testdisk? was genau ist zu tun? Ich habe in meinen recherchen bisher nichts genaueres zu dem thema erfahren.

wäre für jede Hilfe dankbar

**Jack_Herer** · 10.01.17, 13:49

Zitat von Jack_Herer

Hallo erstmal,

Code:

MainMachine ~ # dd if=/dev/mapper/crypt_sdb3 of=/dev/sdb1 bs=2K count=228026880

Und wie ich das jetzt so nochmal durchlese ist mir schon der erste Fehler aufgefallen ich hätte bs=2M nehmen sollen - so wars eigentlich geplant. ohje - deshalb rattert der seit zehn stunden darauf 'rum und ist immer noch erst bei 91GB .... hmm

**florian0285** · 10.01.17, 14:52

Zitat von Jack_Herer

http://unix.stackexchange.com/questi...usb-flashdrive

Hier steht auch gleich in der ersten Antwort ein Lösungsansatz. Arbeite den doch erstmal durch.

In some cases useful info is found in syslog - try
dmesg | tail or so.

Das könnte aufschlussreiche Informationen liefern.

hab ich - hoffentlich - mit count=xxx übergangen.

30 GB oder so Differenz.

Wenn ich das grob umrechne komm ich auf ca. 70GB Differenz. Ich würde mir ne Platte besorgen auf die das gesamte Image passt. Wenn in diesen letzten 30 oder 70GB relevante Daten liegen werden diese nicht mit kopiert.

Jetzt meine laienhafte Frage: Hab ich soweit alles richtig gemacht? Wie geh ich jetzt weiter vor um die Partition wieder herzustellen? mit testdisk? was genau ist zu tun? Ich habe in meinen recherchen bisher nichts genaueres zu dem thema erfahren.

In deinem Link in der Antwort 1 steht eine Vorgehensweise beschrieben.

Wenn du etwas davon nicht verstehst kopier den Abschnitt genau heraus und stell dann speziell dazu die Frage.

Zum besseren Verständnis würde ich auch einfach mal diese drei Wiki-Artikel lesen... Zeit hast du ja jetzt

https://wiki.ubuntuusers.de/LUKS/

https://wiki.ubuntuusers.de/Datenrettung/

https://wiki.ubuntuusers.de/Dateisystemcheck/

Am Rande kannst du auch mal hier rein schauen:

https://wiki.ubuntuusers.de/Logdateien/

https://wiki.ubuntuusers.de/systemd/journalctl/

https://wiki.ubuntuusers.de/dmesg/

Anzumerken wäre nur, dass du die Daten im Image wirklich sicher überprüfen solltest bevor du anfängst irgendwas an der verschlüsselten Platte zurück zu spielen oder ggf. nur fsck drüber laufen zu lassen. Am besten wäre es diese unverschlüsselt als Backup zu extrahieren.

**Jack_Herer** · 10.01.17, 17:58

Zitat von florian0285

Hier steht auch gleich in der ersten Antwort ein Lösungsansatz. Arbeite den doch erstmal durch.

Das könnte aufschlussreiche Informationen liefern.

Wenn ich das grob umrechne komm ich auf ca. 70GB Differenz. Ich würde mir ne Platte besorgen auf die das gesamte Image passt. Wenn in diesen letzten 30 oder 70GB relevante Daten liegen werden diese nicht mit kopiert.

also ich denk daß auf den letzten 30 ... es sind wirklich nur 36 GB Differenz - noch Daten sind, Ich hab die Platte noch nicht so lange weil meine alte Backup Platte physisch das zeitlich gesegnet hat. Die Partition ist zwar 500 GB aber in Wirklichkeit sind nur an die 250 GB an Daten darauf.

Zitat von florian0285

Anzumerken wäre nur, dass du die Daten im Image wirklich sicher überprüfen solltest bevor du anfängst irgendwas an der verschlüsselten Platte zurück zu spielen oder ggf. nur fsck drüber laufen zu lassen. Am besten wäre es diese unverschlüsselt als Backup zu extrahieren.

Ja das hab ich sowieso gemacht: sie aus dem Luks container heraus unverschlüsselt auf eine 'native' ext4 partition kopiert.

**Jack_Herer** · 13.01.17, 16:33

Zitat von florian0285

Hier steht auch gleich in der ersten Antwort ein Lösungsansatz. Arbeite den doch erstmal durch.

Das könnte aufschlussreiche Informationen liefern.

Wenn ich das grob umrechne komm ich auf ca. 70GB Differenz. Ich würde mir ne Platte besorgen auf die das gesamte Image passt. Wenn in diesen letzten 30 oder 70GB relevante Daten liegen werden diese nicht mit kopiert.

In deinem Link in der Antwort 1 steht eine Vorgehensweise beschrieben.

Anzumerken wäre nur, dass du die Daten im Image wirklich sicher überprüfen solltest bevor du anfängst irgendwas an der verschlüsselten Platte zurück zu spielen oder ggf. nur fsck drüber laufen zu lassen. Am besten wäre es diese unverschlüsselt als Backup zu extrahieren.

Also ich hab deine Links alle aufmerksam durchgelesen. Zeit genug war tatsächlich - das kopieren hat volle drei Tage gedauert. Egal.

Jetzt hab ich das abgschlossen. Und ich komm keinen Schritt weiter. Ich bin echt am verzweifeln.

Wenigstens habe ich jetzt ein paar ausführlichere Fehlermeldungen; wenn ich ein mount versuche, dann kommt immer noch die Fehlermeldung wie oben wenn ich: fsck ausführe kommt die Meldung:

Code:

MainMachine ~ # fsck.ext4 -v -f -c /dev/sdb1
e2fsck 1.42.13 (17-May-2015)
ext2fs_open2: Ungültige magische Zahl im Superblock
fsck.ext4: Superblock ungültig, Datensicherungs-Blöcke werden versucht ...
fsck.ext4: Ungültige magische Zahl im Superblock beim Versuch, /dev/sdb1 zu öffnen

Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-
Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-
Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock
beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock
zu starten:
    e2fsck -b 8193 <Gerät>
 oder
    e2fsck -b 32768 <Gerät>

Ich hab auch versucht ext2fs mit -b option und allen angegebenen backups vom superblock. Ohne Erfolg. so wie hier angegeben:

Code:

MainMachine ~ # mke2fs -n -T ext4 /dev/sdb1
mke2fs 1.42.13 (17-May-2015)
Ein Dateisystems mit 114013440 (4k) Blöcken und 28508160 Inodes wird erzeugt.
UUID des Dateisystems: bc67eb6b-c1ff-41ab-9b8c-52e66121c4e3
Superblock-Sicherungskopien gespeichert in den Blöcken: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000

Was mich stutzig macht ist dass mke2fs von 4k Blöcken redet, aber wenn ich fdisk ausführe dann steht da was von 512byte Blöcken? Muss ich da noch etwas umrechnen oder sind in dem Fall einfach die Blöcke vom FS und von der Partition zwei verschiedene Dinge?

Ich weiss dass ich das Problem einmal hatte daß einfach die inkorrekte Partitionsgrösse angegeben wurde und ich das einfach durch zweimaligen aufruf von fdsik behoben worden ist. Bringt aber wohl in dem Fall nichts weil ja fdisk die Partitisonstabelle verändert. Und nicht den Superblock angreift. Hab ich mittlerweile auch kapiert.

Interessant ist auch das Testdisk überhaupt keine Partition anzeigt.

Also ich bin am Ende von meinem - beschränkten - Latein.

Vollkommen verwirrt mich ja dass parted keinen File-type angibt:

Code:

MainMachine ~ # parted /dev/sdb
GNU Parted 3.2
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p                                                                
Model: TOSHIBA External USB 3.0 (scsi)
Disk /dev/sdb: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  467GB   467GB   primary
 2      467GB   500GB   33,0GB  primary  ext4
 3      500GB   1000GB  500GB   primary               lvm

(parted)

fdisk aber schon:

Code:

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sdb: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xc73d7569

Device     Boot     Start        End   Sectors   Size Id Type
/dev/sdb1            2048  912109567 912107520 434,9G 83 Linux
/dev/sdb2       912109568  976566271  64456704  30,8G 83 Linux
/dev/sdb3       976566272 1953525167 976958896 465,9G 8e Linux LVM

**florian0285** · 13.01.17, 17:25

Wenigstens habe ich jetzt ein paar ausführlichere Fehlermeldungen; wenn ich ein mount versuche,

welche denn?

Fdisk zeigt dir den festgelegten Partitionstyp an und parted das unbekannte Dateisystem.

Ich würde mal versuchen auszuschließen, dass da da ggf. nicht doch die verschlüsselten Daten kopiert hast

Code:

cryptsetup luksOpen /dev/sdb1 XYZ
mount /dev/mapper/XYZ

**Jack_Herer** · 13.01.17, 18:30

Zitat von florian0285

welche denn?

Fdisk zeigt dir den festgelegten Partitionstyp an und parted das unbekannte Dateisystem.

Ich würde mal versuchen auszuschließen, dass da da ggf. nicht doch die verschlüsselten Daten kopiert hast

Code:

cryptsetup luksOpen /dev/sdb1 XYZ
mount /dev/mapper/XYZ

also bitte - nein. hab ich nicht. ich meint die fehlermeldung von fsck betreffend den kaputten superblock.

Code:

MainMachine ~ # cryptsetup luksOpen /dev/sdb1 crypt_dm3
Device /dev/sdb1 is not a valid LUKS device.

**Jack_Herer** · 13.01.17, 18:33

ich hab 'nen anderen Gedanken gehabt ob das ev funktionieren könnte: wenn ich das ext4 aus dem crypto-container mit -dd auf die andere Partition ziehe. und dort vorher ein ext4 erstelle. und -dd dann beim kopieren angebe skip=2048 ... könnte das funktionieren? dass er dann quasi den defekten superblock überspringt?

**Jack_Herer** · 13.01.17, 20:20

Zitat von Jack_Herer

ich hab 'nen anderen Gedanken gehabt ob das ev funktionieren könnte: wenn ich das ext4 aus dem crypto-container mit -dd auf die andere Partition ziehe. und dort vorher ein ext4 erstelle. und -dd dann beim kopieren angebe skip=2048 ... könnte das funktionieren? dass er dann quasi den defekten superblock überspringt?

was ich nicht verstehen will ist warum Testdisk auch die Partition nicht findet?

Code:

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdb - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
>* Linux                56776  49 42 60788 111 59   64456704
 P Linux                60788 111 60 60788 176 60       4096




























Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
ext4 blocksize=4096 Large_file Sparse_SB, 33 GB / 30 GiB

**florian0285** · 13.01.17, 20:27

Der Superblock beinhaltet Informationen über das Dateisystem. Also überspringen is nicht.
Wenn man sich das jetzt genauer anschaut ist das ja so, dass du in eine vorhandene Partition geschrieben hast. Mit vorhandener Partitionstabelle. Welche wohl nie exakt genau so ist wie deine Quelle. Also ist da wohl irgendwas inkontsistent. Ich hatte eigentlich gedacht du machst das wie in der Anleitung in ein File.

https://ext4.wiki.kernel.org/index.p...he_Super_Block

Bist du dir überhaupt sicher, dass die ursprünglichen Daten von der originalen Partition noch "erreichbar" sind? Wenn das der Fall ist könntest du mit irgendeinem Datenrecovery-Tool überhaupt versuchen eine einzelne Datei widerherzustelln.

Adere Frage war das Dateisystem blanko ext4 auf der original Partiton? oder steckte da noch LVM oder sonst was dahinter?

Sind denn auf den anderen Partitionen wichtige Daten?

**Jack_Herer** · 13.01.17, 21:13

Zitat von florian0285

Der Superblock beinhaltet Informationen über das Dateisystem. Also überspringen is nicht.
Wenn man sich das jetzt genauer anschaut ist das ja so, dass du in eine vorhandene Partition geschrieben hast. Mit vorhandener Partitionstabelle. Welche wohl nie exakt genau so ist wie deine Quelle. Also ist da wohl irgendwas inkontsistent. Ich hatte eigentlich gedacht du machst das wie in der Anleitung in ein File.

https://ext4.wiki.kernel.org/index.p...he_Super_Block

Bist du dir überhaupt sicher, dass die ursprünglichen Daten von der originalen Partition noch "erreichbar" sind? Wenn das der Fall ist könntest du mit irgendeinem Datenrecovery-Tool überhaupt versuchen eine einzelne Datei widerherzustelln.

Adere Frage war das Dateisystem blanko ext4 auf der original Partiton? oder steckte da noch LVM oder sonst was dahinter?

Sind denn auf den anderen Partitionen wichtige Daten?

na die Ursprungspartition ist ist die sdb3 ... das ist ein LVM für einen Luks-Container. Deshalb zeigt fdisk nur 4MB Grösse an, weil das nur der Header ist. Aber in dem Container ist nur eine einzelne ext4 ... also keine weiteren Verschachtelungen.

und ja ich hab das auf eine neu erstellte ext4 gezogen die Partitionstabelle gilt ja für die gesamte Platte also warum sollte die auf den einzelnen Partitionen anders sein? Die Partitionstabelle ist ja auch korrekt und konsistent. Die Supberblocks sind defekt. und da hab ich die defekten Suberblocks wohl mit -dd mitkopiert. so wie den ganzen Rest der Partition.

War ja auch so das vorher nach dem erstellen der leeren ext4 die korrekt angzeigt wurde. aber als ich dann die Daten drüber gelegt hab wurde sie mir wieder als 'unbekanntes dateiformat' angzeigt. Ist ja auch iwie logisch.

Jedenfalls nach meiner Denkweise. *g*

Aber ich kann noch mal versuchen das in eine Image zu ziehen ... ich meld mich dann in drei Tagen wieder.

**Jack_Herer** · 13.01.17, 21:19

Zitat von florian0285

Der Superblock beinhaltet Informationen über das Dateisystem. Also überspringen is nicht.
Wenn man sich das jetzt genauer anschaut ist das ja so, dass du in eine vorhandene Partition geschrieben hast. Mit vorhandener Partitionstabelle. Welche wohl nie exakt genau so ist wie deine Quelle. Also ist da wohl irgendwas inkontsistent. Ich hatte eigentlich gedacht du machst das wie in der Anleitung in ein File.

https://ext4.wiki.kernel.org/index.p...he_Super_Block

Bist du dir überhaupt sicher, dass die ursprünglichen Daten von der originalen Partition noch "erreichbar" sind? Wenn das der Fall ist könntest du mit irgendeinem Datenrecovery-Tool überhaupt versuchen eine einzelne Datei widerherzustelln.

Adere Frage war das Dateisystem blanko ext4 auf der original Partiton? oder steckte da noch LVM oder sonst was dahinter?

Sind denn auf den anderen Partitionen wichtige Daten?

Ich habe ja die Daten nur aus dem LVM in eine native ext4 verschoben. Aber auf demselben physischen Datenträger. Da hat sich ja an der Partitionstabelle nichts geändert. Also warum die dann inkosistent sein sollte kann ich nicht nachvollziehen.

**florian0285** · 13.01.17, 21:27

Inkonsistent is kein muss is halt nur mal eine Möglichkeit. Weil die Partition z. B. ursprünglich größer sein könnte als die Zielpartition. Du hast einfach mit dd drüber gebügelt das achtet da nicht zwingend drauf.

Was du aber noch genauer erklären müsstest ist deine LVM LUKS ext4 Verschachtelung. Wenn da jetzt LVM mit drin steckt sieht das für mich so aus

Platte -> Partition (sdb3) -> LUKS -> LVM -> ext4

Also könntest du dein geklontes sdb1 jetzt mal mit lvm einbinden und dann nochmal schauen ob du das mounten kannst.

Du sagst aber es ist

Platte -> Partition -> LVM -> LUKS -> ext4

???

Wenn das dann so ist müsstest du ja

cryptsetup luksOpen /dev/mapper/lvm-name crypt_sdb3

benutzen

Nachtrag:
och gott... das ist die selbe Platte... man

Mir steigt das Fieber zu Kopf ich geh ins Bett und schlaf ne Nacht drüber. Vielleicht seh ich das dann klarer

**Jack_Herer** · 13.01.17, 21:42

Zitat von florian0285

Inkonsistent is kein muss is halt nur mal eine Möglichkeit. Weil die Partition z. B. ursprünglich größer sein könnte als die Zielpartition. Du hast einfach mit dd drüber gebügelt das achtet da nicht zwingend drauf.

Was du aber noch genauer erklären müsstest ist deine LVM LUKS ext4 Verschachtelung. Wenn da jetzt LVM mit drin steckt sieht das für mich so aus

Platte -> Partition (sdb3) -> LUKS -> LVM -> ext4

Also könntest du dein geklontes sdb1 jetzt mal mit lvm einbinden und dann nochmal schauen ob du das mounten kannst.

Du sagst aber es ist

Platte -> Partition -> LVM -> LUKS -> ext4

???

Wenn das dann so ist müsstest du ja

cryptsetup luksOpen /dev/mapper/lvm-name crypt_sdb3

benutzen

Nachtrag:
och gott... das ist die selbe Platte... man

Mir steigt das Fieber zu Kopf ich geh ins Bett und schlaf ne Nacht drüber. Vielleicht seh ich das dann klarer

ja aber das mit der inkosinstenz wegen der verschiedenen partitionsgrössen ist ein heisser tip: weil ich hab ja ganz zu anfangs gesagt ich muss das etwas reduzieren mit count=xxx ... weil ich einfach nicht mehr so viel platz hab. ... dann werd ich das doch nochmal auf ein image ziehen. aber bringt das dann was? dann ist ja das image trotzdem wieder eine andere grösse als die urpsrüngliche partition?

ich lass auch sein für heute. mir reichts schon wieder. das ist alles schon wieder soooooo mühsam.

noch'n Nachtrag du hast natürlich recht: ich war da jetzt etwas falsch unterwegs mit dem LVM: deshalb weil beim setup zeigt er Luks container als 'LVM for encryption' ... aber im grunde ist der aufbau ganz simpel:
Platte -> Partition -> LUKS -> ext4

**Jack_Herer** · 14.01.17, 06:47

das ist ja mal interessant:

Code:

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

 1 P Linux                    0  32 33 56776  49 41  912107520



Support for this filesystem hasn't been enable during compilation.