Hallo erstmal,

ich bin nicht sicher ob mir da jemand weiterhelfen kann - aber fragen kostet ja nix.

Folgendes Problem ist aufgetreten: ich hab in meinem System eine interne HD für das laufende System und eine externe für Backups.
Auf der backup Platte ist auch ein 500GiB Luks-Container der eine ext4 Partition enthält.

Nach einem System-upgrade bin ich plötzlich beim mount-Versuch auf die Fehlermeldung gestossen, daß der Superblock defekt sei.

Ich hab dann versucht eine Backup-Kopie vom Superblock zurück zu schreiben, aber es konnte keine Kopie gefunden werden.

Mein starker Verdacht ist, daß beim dechriffieren beim mount-Vorgang etwas schief gelaufen ist und deshalb die Daten quasi nur mehr 'verscrumbeld' vorhanden sind.

Auch ein Rettungsversuch mit foremost ist fehlgeschlagen: foremost -wt all hat keine einzige Datei auf der Partition resp. dem image davon gefunden.

Jetzt meine Frage: sind die Daten unrettbar verloren? oder gibts eine Möglichkeit doch noch an sie ran zu kommen?

Danke mal.

Kann gern Fehlermeldungen oder Details zu System u. ä. posten wenn jemand eine Möglichkeit sieht.

hi,

hast du die Fehlermeldungen noch? Wenn ja bitte posten

Den LUKS-Container kannst du nach Eingabe deines Passworts öffnen, ja? Probleme macht "nur" das ext4 filesystem, das in dem Container liegt?

Zitat von cosinus

hi,

hast du die Fehlermeldungen noch? Wenn ja bitte posten

Den LUKS-Container kannst du nach Eingabe deines Passworts öffnen, ja? Probleme macht "nur" das ext4 filesystem, das in dem Container liegt?

Ja, Luks lässt sich öffnen - Probleme macht das ext4:

MainMachine 8e9eb1a2-3168-46d2-bccb-a3b127ca6427 # mount -o loop ./test.img /media/tmp
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

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

MainMachine 8e9eb1a2-3168-46d2-bccb-a3b127ca6427 # e2fsck -f ./test.img 
e2fsck 1.42.13 (17-May-2015)
ext2fs_open2: Ungültige magische Zahl im Superblock
e2fsck: Superblock ungültig, Datensicherungs-Blöcke werden versucht ...
e2fsck: Ungültige magische Zahl im Superblock beim Versuch, ./test.img 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>
         

MainMachine 8e9eb1a2-3168-46d2-bccb-a3b127ca6427 # mke2fs -n -t ext4 ./test.img
mke2fs 1.42.13 (17-May-2015)
Warnung: Die Geometrie des Gerätes „./test.img“ kann nicht bestimmt werden
Ein Dateisystems mit 82455552 (4k) Blöcken und 20619264 Inodes wird erzeugt.
UUID des Dateisystems: 479ef4d3-924f-40c7-bd9b-90c9ca3c7b1a
Superblock-Sicherungskopien gespeichert in den Blöcken: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968
         

MainMachine 8e9eb1a2-3168-46d2-bccb-a3b127ca6427 # e2fsck -f -b32768 ./test.img 
.
.
.
MainMachine 8e9eb1a2-3168-46d2-bccb-a3b127ca6427 # e2fsck -f -b2654208 ./test.img 
e2fsck 1.42.13 (17-May-2015)
e2fsck: Ungültige magische Zahl im Superblock beim Versuch, ./test.img 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>
         

MainMachine 8e9eb1a2-3168-46d2-bccb-a3b127ca6427 # dumpe2fs  ./test.img | grep -i superblock
dumpe2fs 1.42.13 (17-May-2015)
dumpe2fs: Ungültige magische Zahl im Superblock beim Versuch, ./test.img zu öffnen
Es kann kein gültiger Dateisystem-Superblock gefunden werden.
         

Hast du das Filesystem in eine img-Datei erstellt?

Ich kenn das eher anders, man erstellt mittels LVM logical volumes im LUKS-Container, diese logical volumes bekommen dann ein filesystem wie ext4 oder so...

Poste mal die Ausgaben von blkid und lsblk

Wir wurde das ext4-Dateisystem denn immer gemountet? Poste daher auch mal am besten den Inhalt der beiden Konfigfiles /etc/fstab und /etc/crypttab

Zitat von cosinus

Hast du das Filesystem in eine img-Datei erstellt?

Ich kenn das eher anders, man erstellt mittels LVM logical volumes im LUKS-Container, diese logical volumes bekommen dann ein filesystem wie ext4 oder so...

Poste mal die Ausgaben von blkid und lsblk

Wir wurde das ext4-Dateisystem denn immer gemountet? Poste daher auch mal am besten den Inhalt der beiden Konfigfiles /etc/fstab und /etc/crypttab

Nein - das filesystem liegt natürlich in einem 'LVM for encryption' ... das ist nur die backup-Kopie die ich aus dem Container 'raus gezogen habe weil ich nicht auf den original Partitionen herumfuhrwerken wollte:

MainMachine ~ # dd if=/dev/mapper/crypt_sdb3 of=/media/bernhard/8e9eb1a2-3168-46d2-bccb-a3b127ca6427/test.img bs=2M count=204800
         

oh man => Frage an die Profis: Datenrettung aus Luks-Container


Hättest ja mal nen Ton sagen können, dass du Crosspostings machst

Zitat von cosinus

oh man => Frage an die Profis: Datenrettung aus Luks-Container


Hättest ja mal nen Ton sagen können, dass du Crosspostings machst

Die Frage war ja nur ob man die verschlüsselten Daten retten kann - nicht das grundsätzliche zur Datenrettung.

Ja, aber dann hätte man schon vorher gesehen was ihr da gemacht habt!
So lässt du die Helfer hier den gleichen Kram nochmal "erfinden" obwohl das schon längst durchgekaut ist

Es kann dir auch niemand sagen was bei dem system-upgrade passiert ist. Sind da irgendwelche Logs zu da? Was genau hast du von was auf was hochgezogen? Und warum steckte eine Backupplatte während des Upgrades am System

Zitat von cosinus

Ja, aber dann hätte man schon vorher gesehen was ihr da gemacht habt!
So lässt du die Helfer hier den gleichen Kram nochmal "erfinden" obwohl das schon längst durchgekaut ist

Es kann dir auch niemand sagen was bei dem system-upgrade passiert ist. Sind da irgendwelche Logs zu da? Was genau hast du von was auf was hochgezogen? Und warum steckte eine Backupplatte während des Upgrades am System

Also ich hab gestern noch gesucht obs noch log-files gibt vom setup: aber ich hab die Platte nachdem Setup ja noch ansprechen können. Drei- oder viermal der Fehler ist erst danach aufgetreten. Und ohne ersichtlichen Grund: Es gab keinen Headcrash, keinen Stromausfall kein unsauberes umount oder sonstiges. Völlig unerklärlich.

Aber ich muß mich wohl damit abfinden daß die Daten weg sind. Was zwar schmerzt. Aber: that's life.

Wie sehen denn jetzt die Ausgaben von lsblk usw. aus wenn du den LUKS-Container entsperrt hast?

Zitat von cosinus

Wie sehen denn jetzt die Ausgaben von lsblk usw. aus wenn du den LUKS-Container entsperrt hast?

MainMachine ~ # cryptsetup luksOpen /dev/sdb3 crypt-dm3
Geben Sie die Passphrase für »/dev/sdb3« ein: 
MainMachine ~ # lsblk
NAME           MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda              8:0    0  74,5G  0 disk  
├─sda1           8:1    0   487M  0 part  /boot
├─sda2           8:2    0     1K  0 part  
└─sda5           8:5    0  74,1G  0 part  
  └─sda5_crypt 252:0    0  74,1G  0 crypt 
    ├─mint--vg-root
    │          252:1    0  72,6G  0 lvm   /
    └─mint--vg-swap_1
               252:2    0   1,5G  0 lvm   [SWAP]
sdb              8:16   0 931,5G  0 disk  
├─sdb1           8:17   0 465,7G  0 part  /media/bernhard/8e9eb1a2-3168-46d2-bcc
└─sdb3           8:19   0 465,9G  0 part  
  └─crypt-dm3  252:3    0 465,9G  0 crypt 
sr0             11:0    1  1024M  0 rom   
MainMachine ~ #
         

MainMachine ~ # blkid
/dev/mapper/sda5_crypt: UUID="6d1ZF3-1TVw-x1xS-1VjI-QzgI-HXbi-e3acwm" TYPE="LVM2_member"
/dev/mapper/mint--vg-root: UUID="0a1b0fdb-bd9f-4b58-8dd6-4a90e8845e52" TYPE="ext4"
/dev/sda1: UUID="96a68837-154a-411a-bcee-aa637d77a776" TYPE="ext2" PARTUUID="6cf886e3-01"
/dev/sda5: UUID="d0383092-6d95-4f19-af96-451bb2ef38fc" TYPE="crypto_LUKS" PARTUUID="6cf886e3-05"
/dev/sdb1: UUID="8e9eb1a2-3168-46d2-bccb-a3b127ca6427" TYPE="ext4" PARTUUID="c73d7569-01"
/dev/sdb3: UUID="d53260e4-3b60-477c-8179-2f4d43c328cd" TYPE="crypto_LUKS" PARTUUID="c73d7569-03"
/dev/mapper/mint--vg-swap_1: UUID="fc42fc62-7a73-4be9-a405-1c2081738a2e" TYPE="swap"
         

was genau sonst meintest du mit "usw"?

damit meinte ich blkid und auch den Inhalt von fstab und crypttab

Zitat von cosinus

damit meinte ich blkid und auch den Inhalt von fstab und crypttab

dann noch die fstab ...

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/mint--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=96a68837-154a-411a-bcee-aa637d77a776 /boot           ext2    defaults        0       2
/dev/mapper/mint--vg-swap_1 none            swap    sw              0       0
         

... und crypttab:

sda5_crypt UUID=d0383092-6d95-4f19-af96-451bb2ef38fc none luks,discard
         

Gut. Ich "spiele" hier grad selber mit LUKS herum weil ich das auch nicht jeden Tag mache...

sdb              8:16   0 931,5G  0 disk  
├─sdb1           8:17   0 465,7G  0 part  /media/bernhard/8e9eb1a2-3168-46d2-bcc
└─sdb3           8:19   0 465,9G  0 part  
  └─crypt-dm3  252:3    0 465,9G  0 crypt
         

Fehlt da nicht sdb2? War das schon immer so? Ok, Nebenkriegsschauplatz

Wenn du "sauber" luksOpen /dev/sdb3 crypt-dm3 machen kannst ist das Thema ja gegessen,Partition /dev/sdb3 ist entsperrt und wird nach /dev/mapper/crypt-dm3 (unverschlüsselt) abgebildet. Dann müsste blkid auch nen Eintrag für /dev/mapper/crypt-dm3 haben und die UUID des Dateisystems anzeigen. Warum das Dateisystem dadrauf zerstört wurde kann ich dir jetzt aber auch nicht sagen (ohne unmount vllt rausgezogen? )

Dateisystem auf sdb1 ist aber ok? Was war auf crypt-dm3, ext4?

Ist die Platte selbst denn noch okay? Was sagt ein smartctl?

Mehr fällt mir so auch im Moment nicht ein, es wurde ja auch schon so gut wie alles in deinem Thread in linuxforen.de auch schon probiert...

nein das war nicht immer so:

das hab ich jetzt so gemacht im Zug des - leider sinnlosen - Datenrettungsversuchs.

Auf der Platte waren vorher zwei ntfs-Partitionen (1&2) die ich dann - weil ich ja sowieso das win endgültig runter geschmissen hab zusammengelegt hab auf eine ext4 ... auch aus dem Grund weil ich eben sonst nicht genügend Platz hab um ein 500 GiB Image zu ziehen. Oder wenigstens 400 GB ... die Platte war ja sowieso nicht ganz voll.

Und die Platte ist in Ordnung: das paradoxe daran ist ja: ich hatte vorher eine ältere 250GiB HD und die hat dann angefangen so seltsame Geräusche von sich zu geben und I/O errors ... hab ich mir gedacht: upsi: schleunigst eine neue besorgen und hab die von der Platte auf die neue 1TB 'rüber gerettet. Die Platte ist nichtmal zwei Monate alt.

und weisst was: ich hab gestern nachgesehen ob ich nicht noch die alte herum liegen hab: und nein, hab ich entsorgt.

es war ein ext4 drauf. Und so wie da angeführt wird, daß es anscheinend ein gängiges Problem ist daß Luks in Verbindung mit journaled ext4 Probleme macht kann ich jedem nur dringend empfehlen das journalling abzustellen wenn eine Luks-Partition mit ext4 erstellt wird. (hxxp://unix.stackexchange.com/questions/281349/mount-error-when-automounting-a-luks-encrypted-usb-flashdrive)

... bloss aus meiner leidvollen Erfahrung gesprochen.

Und genau das ist ja was mich so verduzt macht: es gab weder ein unsauberes umount, noch einen Stromausfall, oder einen headcrash oder sonst irgendeinen schreib-/lesefehler.
Die Partition war einfach nach einem reboot verschwunden. Fertig. ... wobei noch nichtmal veschwunden: einfach als unbekannter-Typ eingetragen.

... naja. was solls weg ist weg. ... ich werd die Partition aber trotzdem noch aufheben. vl stolpert ja in Zukunft jemand über einen Lösungsvorschlag.

... wobei der eigentlich Grund für das Cross-Posting war ja der, daß ich da den Thread über die Crypto-Trojaner gelesen hab und mir gedacht hab ich frag mal nach weil vl. gibt es eine Möglichkeit die Rohdaten zu dechriffieren so daß ich wenigstens mit foremost o.ä. etwas retten kann.

Immerhin weiss ich ja die Pass-Phrase und ich kenn die Methode mit der verschlüsselt wurde, weil ich das ja selbst erstellt hab. wobei ich mir nicht mehr sicher bin ob das jetzt 256aes oder 512 war. aber das könnte ich herausfinden.

florian0285 hat da einen Satz fallen lassen

Eigentlich nicht. Ich hab nur beim rumschnöckern eine Anleitung gefunden wo da noch durch ccrypt durchgeleitet wird und wollte nen Fehler ausschließen

... vl. kann ich das mal eruieren. beim -dd mit einer Pype über ccrypt leiten oder so in der Art. Eine Idee dazu?