Frage an die Profis: Datenrettung aus Luks-Container

[Jack_Herer]

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/questions/281349/mount-error-when-automounting-a-luks-encrypted-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:


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.


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]

Hallo erstmal,



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]

http://unix.stackexchange.com/questions/281349/mount-error-when-automounting-a-luks-encrypted-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 :p

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]

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.




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]

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:


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:


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:


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:


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]

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 :D



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

[Jack_Herer]

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 :D



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.


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

[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?

[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?


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]

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.php/Ext4_Disk_Layout#The_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]

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.php/Ext4_Disk_Layout#The_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]

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.php/Ext4_Disk_Layout#The_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]

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 :D
Mir steigt das Fieber zu Kopf ich geh ins Bett und schlaf ne Nacht drüber. Vielleicht seh ich das dann klarer :o

[Jack_Herer]

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 :D
Mir steigt das Fieber zu Kopf ich geh ins Bett und schlaf ne Nacht drüber. Vielleicht seh ich das dann klarer :o


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

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]

das ist ja mal interessant: :rolleyes:



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.

[Jack_Herer]

also ich werde jetzt folgendes machen: ich werde das ganze nochmal dumpen ... diesmal in ein image-file. ich hoffe dass ich dann wenigstens die rohdaten hab. mal sehen ob das etwas bringt.

[florian0285]

Na dann bis übermorgen [emoji12]

[Jack_Herer]

Na dann bis übermorgen [emoji12]

hahaha ... nein, nein. diesmal hab ich wirklich mit bs=2M gearbeitet. lol.

[florian0285]

Also aus Langeweile hab ich das jetzt mal verkürzt durch gearbeitet.

Ich hab mir nen 20 MB LUKS-File-Container erstellt.



dd if=/dev/zero of=crypt.con bs=1M count=20

losetup /dev/loop0 ./crypt.con

cryptsetup luksFormat -c towfish-xts-plain64 -s 512 -h sha512 -y /dev/loop0

losetup -d /dev/loop0

cryptsetup luksOpen ./crypt.con babum

mkfs -t ext4 /dev/mapper/babum



Dann gemountet ne Textdatei erstellt ungemountet und mit dd ein unverschlüsseltets Abbild erstellt es gemountet und siehe da das Textfile ist drinnen.




mkdir test

mount /dev/mapper/babum ./test

echo "hodor" > ./test/hodor.txt

umount ./test

dd if=/dev/mapper/babum of=hodor.con

losetup loop1 hodor.con

mount /dev/loop1 ./test


Also das Vorgehen sollte so eigentlich funktionieren, wenn die Daten richtig kopiert wurden und auf der original Platte nicht von Haus aus schon "zerstört" sind.

Was ich gestern eigentlich noch anmerken wollte. Ein Backup auf der selben Platte wäre nicht zu empfehlen, weil ggf. riskant. Aber das musst du entscheiden ;)


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?
Das bringt dir mindestens so viel, dass eventuelle Daten im "verlorenen" Bereich mit im Image-File sind. 30GB sind ja nicht wenig. Die Größe des Image-Files sollte eigentlich exakt so groß sein wie die originale Partition. DD fertigt hier eine 1:1 Kopie an. Daher ergibt sich mit einem File auch weniger das Problem eine entsprechend exakte Zielpartition zu konstruieren und das Filesystem hat keinen Grund wegen Unstimmigkeiten mit der Partitionstabelle rumzumeckern.

Wenns mal wieder länger dauert:

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

https://wiki.ubuntuusers.de/gddrescue/

http://www.linux-community.de/Internal/Artikel/Print-Artikel/LinuxUser/2004/08/Mit-dd_rescue-defekte-Partition-wiederherstellen

[Jack_Herer]

Also aus Langeweile hab ich das jetzt mal verkürzt durch gearbeitet.

Ich hab mir nen 20 MB LUKS-File-Container erstellt.



dd if=/dev/zero of=crypt.con bs=1M count=20

losetup /dev/loop0 ./crypt.con

cryptsetup luksFormat -c towfish-xts-plain64 -s 512 -h sha512 -y /dev/loop0

losetup -d /dev/loop0

cryptsetup luksOpen ./crypt.con babum

mkfs -t ext4 /dev/mapper/babum



Dann gemountet ne Textdatei erstellt ungemountet und mit dd ein unverschlüsseltets Abbild erstellt es gemountet und siehe da das Textfile ist drinnen.




mkdir test

mount /dev/mapper/babum ./test

echo "hodor" > ./test/hodor.txt

umount ./test

dd if=/dev/mapper/babum of=hodor.con

losetup loop1 hodor.con

mount /dev/loop1 ./test


Also das Vorgehen sollte so eigentlich funktionieren, wenn die Daten richtig kopiert wurden und auf der original Platte nicht von Haus aus schon "zerstört" sind.

Was ich gestern eigentlich noch anmerken wollte. Ein Backup auf der selben Platte wäre nicht zu empfehlen, weil ggf. riskant. Aber das musst du entscheiden ;)


Das bringt dir mindestens so viel, dass eventuelle Daten im "verlorenen" Bereich mit im Image-File sind. 30GB sind ja nicht wenig. Die Größe des Image-Files sollte eigentlich exakt so groß sein wie die originale Partition. DD fertigt hier eine 1:1 Kopie an. Daher ergibt sich mit einem File auch weniger das Problem eine entsprechend exakte Zielpartition zu konstruieren und das Filesystem hat keinen Grund wegen Unstimmigkeiten mit der Partitionstabelle rumzumeckern.

Wenns mal wieder länger dauert:

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

https://wiki.ubuntuusers.de/gddrescue/

http://www.linux-community.de/Internal/Artikel/Print-Artikel/LinuxUser/2004/08/Mit-dd_rescue-defekte-Partition-wiederherstellen

Hast Du das etwa in Zweifel gezogen? :p

Also img-gezogen ... aber wie erwartet:


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.


Das einzige was jetzt noch bleibt - aber damit bin ich echt überfordert:


MainMachine 8e9eb1a2-3168-46d2-bccb-a3b127ca6427 # hexdump -s0 -n2048 -C ./test.img
00000000 21 49 74 76 2e bd 99 e7 84 ef 45 0f 96 9d 24 fd |!Itv......E...$.|
00000010 32 ec 1c 46 11 9a eb d2 1c 23 ab 97 d0 42 45 04 |2..F.....#...BE.|
00000020 22 55 02 2c c5 23 4d 07 d4 e0 fb ed 9a dc 12 9e |"U.,.#M.........|
00000030 33 44 95 02 4c 55 f0 aa 36 05 42 c9 0e 9e a0 13 |3D..LU..6.B.....|
00000040 98 3e 08 6b d5 a0 4d 7a 17 2f 22 11 0e f3 cb 0c |.>.k..Mz./".....|
00000050 d6 2e 04 a4 04 2a a0 f0 00 13 66 f3 c5 53 70 6f |.....*....f..Spo|
00000060 6a bb 69 98 a0 02 f1 94 e5 8e 1e f0 55 8c d7 fe |j.i.........U...|
00000070 ce 1c c5 b6 96 33 bd 40 07 d2 ab 31 d6 42 1b f8 |.....3.@...1.B..|
00000080 a9 c6 61 7c 5a b5 d3 30 08 52 2e 0c c2 5e bb f7 |..a|Z..0.R...^..|
00000090 10 54 b0 2c 3b e5 e2 1b ef a0 67 6f e1 a6 8c d4 |.T.,;.....go....|
000000a0 e1 e5 0c 16 0e e9 d7 63 20 f4 db 3b c6 1e ec 3d |.......c ..;...=|
000000b0 89 62 81 78 f2 66 7d 00 3b 6b 53 91 f7 24 51 05 |.b.x.f}.;kS..$Q.|
000000c0 10 a4 97 3c ec 9b cb 50 6a 04 ca a8 08 ef 6a 48 |...<...Pj.....jH|
000000d0 4a cd 36 d5 05 e0 f3 f9 ed 75 47 1e f9 15 c0 0e |J.6......uG.....|
000000e0 f9 92 38 bb 2b 1d df d1 b6 02 35 2d 73 06 4f 4a |..8.+.....5-s.OJ|
000000f0 37 01 10 44 23 63 a1 85 76 10 51 01 f8 8d 79 eb |7..D#c..v.Q...y.|
00000100 15 67 a5 02 1a 42 e3 c0 a9 7a 8c 3f 95 45 f9 39 |.g...B...z.?.E.9|
00000110 96 18 e5 b4 7e 78 c5 95 1d 0b 94 0e fb 39 5e e9 |....~x.......9^.|
00000120 08 41 e3 58 1e 46 2e 91 5b 70 ab b2 00 1a 86 f0 |.A.X.F..[p......|
00000130 0b d9 f4 02 15 ad bd f4 b4 2a 97 db d7 5f 3a 23 |.........*..._:#|
00000140 b6 6d ab 37 a9 f4 1b 28 6f ae ab 71 fd 1f ef d2 |.m.7...(o..q....|
00000150 c5 ca a2 52 11 20 44 f6 a9 7b 85 75 76 28 d8 20 |...R. D..{.uv(. |
00000160 3c c1 5f 98 b0 20 7c 38 0c 5c 17 15 b3 34 2f 81 |<._.. |8.\...4/.|
00000170 aa f4 0c 30 45 0a 16 fe b6 38 f4 d8 bf f4 c5 1f |...0E....8......|
00000180 c7 6a dc f0 6f d1 95 e9 08 13 da 5c 6d 22 c7 5c |.j..o......\m".\|
00000190 4c c6 90 28 26 ab f6 ab 82 db 50 8a 4f 05 a7 c5 |L..(&.....P.O...|
000001a0 8c 38 c5 2e 0b 16 97 ef 3f 87 4f b4 27 bb 23 66 |.8......?.O.'.#f|
000001b0 1d ee d6 c0 0c be 9b d4 e5 0e 74 5b ac d1 5b 4b |..........t[..[K|
000001c0 da fb 63 2f ea ec ff 4c 8c 9f ba 90 d2 d5 c5 c7 |..c/...L........|
000001d0 a2 2d c7 80 04 7c 71 07 42 3b 48 c3 58 af 6d d2 |.-...|q.B;H.X.m.|
000001e0 d3 c5 5f 71 cb 7b cf e1 f8 9e d3 3a 3a 5b df a0 |.._q.{.....::[..|
000001f0 36 88 ea 10 42 9f ea 30 4a 2d e0 db 6b 5f 72 b7 |6...B..0J-..k_r.|
00000200 c5 09 88 39 b2 19 56 1b 1a 95 5e bc 4e a8 6d 93 |...9..V...^.N.m.|
00000210 54 79 40 57 d4 44 78 7e 4e b7 c3 be bb 88 a0 88 |Ty@W.Dx~N.......|
00000220 42 59 d0 81 8c b3 15 fa 0e 45 4e 8d 6d d3 18 41 |BY.......EN.m..A|
00000230 3b e3 bb 94 44 e1 7e 33 9a 9f 75 35 34 44 34 ca |;...D.~3..u54D4.|
00000240 c8 6c ca 2d e5 4b 87 d2 f5 eb dd 7c 37 4c 40 41 |.l.-.K.....|7L@A|
00000250 53 6c 58 44 ec 2a e4 b6 a7 84 5a 90 e6 a8 45 8c |SlXD.*....Z...E.|
00000260 9e 02 34 73 02 62 55 5f 0f 1d 84 b6 e8 36 8c 91 |..4s.bU_.....6..|
00000270 ea bc 39 12 d3 8c 15 ff 11 f2 d9 b7 df 9d ab 9a |..9.............|
00000280 33 1c 93 39 70 23 65 09 e4 51 b7 da 4f 3e 2b a5 |3..9p#e..Q..O>+.|
00000290 39 31 81 d5 9b f8 45 c1 15 83 46 8b f9 de da 66 |91....E...F....f|
000002a0 92 76 81 1b 19 35 df 86 31 9b 0c ab f0 9b b0 f2 |.v...5..1.......|
000002b0 3b 71 8f 05 19 c6 14 48 27 ce 77 71 9f 1f 32 88 |;q.....H'.wq..2.|
000002c0 d1 89 43 64 d6 6a 31 93 85 7c ae b7 a8 60 bb ef |..Cd.j1..|...`..|
000002d0 e0 33 59 d8 86 ba 9b 37 b4 81 ee 6c 4e 08 b4 cc |.3Y....7...lN...|
000002e0 e6 38 c5 3b 8b 6e 0a af 35 56 fe 47 29 c8 6b ca |.8.;.n..5V.G).k.|
000002f0 b7 fc b0 00 27 d0 53 f7 60 47 44 ee d9 ec 39 cf |....'.S.`GD...9.|
00000300 cf 38 a8 68 7c 44 b4 57 31 4b 61 36 36 af bb 16 |.8.h|D.W1Ka66...|
00000310 19 23 eb c3 71 96 47 f2 79 2f 1d 1f 6b cc 0f 86 |.#..q.G.y/..k...|
00000320 5a 53 b5 28 4a bf b0 bf 39 00 a3 d5 a7 00 4d a1 |ZS.(J...9.....M.|
00000330 ee 59 fd e8 52 11 0c c5 d3 17 c7 66 a4 e3 a9 f0 |.Y..R......f....|
00000340 57 30 33 e7 b0 80 3a 40 39 e6 ac 09 73 c0 c4 49 |W03...:@9...s..I|
00000350 84 17 05 c3 a9 d0 26 a7 24 47 a8 d6 bb 30 5a 99 |......&.$G...0Z.|
00000360 85 83 c0 fd 10 8b 5e 48 5b 3e 3a 03 8f 01 be 6b |......^H[>:....k|
00000370 2c 91 6e 9c fa 67 63 d1 fb 6c ac 8f 83 3a 56 bd |,.n..gc..l...:V.|
00000380 2b b2 f6 7f a1 af dc 5d 82 ed ff d4 78 62 ee fa |+......]....xb..|
00000390 42 3f eb ed 73 3c 64 be 51 7c e8 36 52 49 85 27 |B?..s<d.Q|.6RI.'|
000003a0 31 04 10 1b 68 eb 80 91 38 97 47 16 61 08 61 a6 |1...h...8.G.a.a.|
000003b0 be 3a 7c 50 40 11 b5 b5 cd 3f 50 80 0c 5a 30 d1 |.:|P@....?P..Z0.|
000003c0 22 ce 4b 68 54 40 48 67 75 86 d1 3b 52 17 05 25 |".KhT@Hgu..;R..%|
000003d0 cb 44 27 b3 73 b1 37 1b 03 5e 79 53 cd b0 ad d2 |.D'.s.7..^yS....|
000003e0 aa 51 20 ca 8a be 94 37 b9 c0 de fc 9a b0 3e 33 |.Q ....7......>3|
000003f0 92 19 ac 29 04 d3 75 ff 5d b1 2f 2c 6d 3f be bb |...)..u.]./,m?..|
00000400 b7 7d a1 af b5 f4 9b 1c c5 e5 55 52 9a ab 4c 73 |.}........UR..Ls|
00000410 16 88 0b 1c c3 44 f3 6c 19 3f 43 b6 54 6c 14 5c |.....D.l.?C.Tl.\|
00000420 5d d9 57 7e 44 8d d7 91 b8 01 c1 00 e3 e8 81 e1 |].W~D...........|
00000430 5b 40 9b e9 52 a9 7c 20 68 2b dc ae 2c 87 40 db |[@..R.| h+..,.@.|
00000440 d9 98 39 16 59 b2 39 69 ec 14 5e d1 6a da e8 e5 |..9.Y.9i..^.j...|
00000450 99 5c 8d a5 18 ff 63 ee 89 56 37 b8 e6 b3 c2 c3 |.\....c..V7.....|
00000460 45 30 7a f4 89 fe 09 f0 e5 6b 5b 90 2e 6f 9b e9 |E0z......k[..o..|
00000470 c9 75 23 16 a4 bc 10 4b fe ae ce 6c 40 09 2c b2 |.u#....K...l@.,.|
00000480 81 ba 4e 7e 5d 3f ab 21 5a c9 c5 f0 5f 58 29 24 |..N~]?.!Z..._X)$|
00000490 7d c6 fc 5b 1c c6 48 5f 34 1c f7 2c b8 99 df 5c |}..[..H_4..,...\|
000004a0 74 9b a7 2d cb 4b ce 25 64 d9 df ab 34 0e 26 63 |t..-.K.%d...4.&c|
000004b0 19 fb 7b aa 3a df 23 ad 42 e6 92 d5 93 b4 65 2f |..{.:.#.B.....e/|
000004c0 2d c7 8e 05 1b a1 73 52 ea 1b 9c d1 dc 6d b6 c2 |-.....sR.....m..|
000004d0 8e 12 6b 32 4f ff f4 f4 08 09 af 50 aa 03 42 e5 |..k2O......P..B.|
000004e0 95 05 0a 56 48 f3 52 21 ff 29 f6 d1 32 88 fb 79 |...VH.R!.)..2..y|
000004f0 c6 9e 7e 21 82 61 c4 58 05 e5 96 10 50 16 4c 5c |..~!.a.X....P.L\|
00000500 9e 0c 5a 50 80 23 2a 13 89 28 f3 57 fa 0a 64 aa |..ZP.#*..(.W..d.|
00000510 07 fa 54 38 a9 80 6f e7 62 0a 45 ef f2 38 73 c6 |..T8..o.b.E..8s.|
00000520 21 54 02 f6 d7 a9 bd 84 12 de a3 5b 67 48 4c ca |!T.........[gHL.|
00000530 69 c0 84 e5 a2 f8 11 21 98 b0 34 30 e8 23 da b5 |i......!..40.#..|
00000540 ae b9 ea 9b 0f 1b 9d c1 33 72 e4 76 c5 17 45 ee |........3r.v..E.|
00000550 02 66 6d 9c 75 9c 52 ab d4 13 a5 0c a5 09 f7 cf |.fm.u.R.........|
00000560 d6 35 a9 60 61 e1 4d 83 56 dc 43 4b 33 1b c0 ca |.5.`a.M.V.CK3...|
00000570 0e 7d 6d 20 fb 4e 96 a5 81 2f 9e 04 73 2d 6b 94 |.}m .N.../..s-k.|
00000580 14 ed 2a 39 03 aa 5d 9b 74 5b ce 02 8e 3d 14 81 |..*9..].t[...=..|
00000590 cf 7c 67 3f 37 38 57 62 0f 8c f0 34 3d 96 8f 62 |.|g?78Wb...4=..b|
000005a0 6b 14 5f a9 e2 ca 50 8c c0 19 10 a9 2a a5 1e c8 |k._...P.....*...|
000005b0 00 b6 4a 97 d6 74 d8 14 68 c5 4b 57 ce c1 f5 18 |..J..t..h.KW....|
000005c0 2f c5 ba 36 48 d5 de b8 30 62 8c 17 2a a1 08 96 |/..6H...0b..*...|
000005d0 93 8e 8e 45 e8 3d 9b c7 0b 20 1c c5 7e 2a b1 ac |...E.=... ..~*..|
000005e0 5f 66 a0 ec f6 83 c0 ac e3 f8 e7 7e 11 40 f8 40 |_f.........~.@.@|
000005f0 8b 29 33 9d 35 e7 cf 59 3f b2 8b 23 56 8f d6 f7 |.)3.5..Y?..#V...|
00000600 6d 0f 4d 9b 13 5e 1e b0 9b c3 d2 41 3a 71 78 9a |m.M..^.....A:qx.|
00000610 66 38 ac 99 58 77 b5 53 23 4c a0 12 cd c1 1e 58 |f8..Xw.S#L.....X|
00000620 3b a6 14 c2 59 5f 59 a9 6d ed 38 b9 a9 97 07 9e |;...Y_Y.m.8.....|
00000630 a7 01 dc 20 6d c8 bc b8 fa 8d 4c 5f dd ea 13 f5 |... m.....L_....|
00000640 ab 2e e2 14 d0 e4 60 b6 11 d1 3d e2 9d 7b eb b7 |......`...=..{..|
00000650 c8 7a c1 2d 37 9f b9 1b 9a 96 7b f9 32 6c 85 21 |.z.-7.....{.2l.!|
00000660 db 71 97 ae d8 1a 5d 9e fa c5 8d 96 68 48 3f 3d |.q....].....hH?=|
00000670 af 3e d1 cb 1a 27 e7 0d c8 b2 fa e8 32 e4 c4 51 |.>...'......2..Q|
00000680 fe 6c a9 d6 7b 60 0d b4 8d f2 48 60 08 1c 00 60 |.l..{`....H`...`|
00000690 6a b6 00 75 09 12 90 72 36 d2 47 a3 30 94 d1 d1 |j..u...r6.G.0...|
000006a0 35 3b 74 84 cd 4d 20 7b e5 9c 29 97 7d 8d 48 ab |5;t..M {..).}.H.|
000006b0 52 00 98 0f aa 26 a9 ad 4f be e4 a0 43 f6 9d f4 |R....&..O...C...|
000006c0 24 6c 06 f6 51 99 52 52 ee 00 86 60 b5 dd 8d 42 |$l..Q.RR...`...B|
000006d0 b0 97 b8 14 fd 5c b8 ba f9 72 53 6b 68 e3 d0 8a |.....\...rSkh...|
000006e0 72 b5 cd 93 3d 9d 4f a1 3f 9f 28 22 83 41 cc 42 |r...=.O.?.(".A.B|
000006f0 fc a3 16 18 bb 25 90 e7 bf 86 bb 7e 81 0b af dd |.....%.....~....|
00000700 2a d3 08 82 57 2c c9 6b ed 3e 13 a8 a9 6d d6 7a |*...W,.k.>...m.z|
00000710 da 84 78 3c c5 3f 62 e7 d4 75 8f 6c 5e c1 db 86 |..x<.?b..u.l^...|
00000720 ac c7 b6 7a bf 74 02 5a 7d 80 f5 e4 95 f1 2f 68 |...z.t.Z}...../h|
00000730 b7 22 3d 6b fd 85 a9 4d 77 38 f7 31 82 4f db 13 |."=k...Mw8.1.O..|
00000740 65 dc 07 08 e6 68 70 50 93 e8 7e d4 c4 9e b5 cf |e....hpP..~.....|
00000750 1a 01 19 1e 8f 45 3c cc cf aa 00 c7 a4 dc f1 b4 |.....E<.........|
00000760 ad fb 84 74 8a 22 c1 0b 91 bb 5d ca 5b 29 7a 7d |...t."....].[)z}|
00000770 3e 34 cc 21 15 3b e6 09 8e f4 66 a4 1c f0 19 23 |>4.!.;....f....#|
00000780 0a 92 3a 86 06 9c ea d2 db 45 ee 5c 77 fe 10 33 |..:......E.\w..3|
00000790 98 86 47 12 a4 41 f9 49 4f d5 f9 fb 06 9b 18 fb |..G..A.IO.......|
000007a0 92 2f 5d 67 82 70 67 a4 89 0f 16 7e a5 f9 b6 b6 |./]g.pg....~....|
000007b0 5c 74 60 3c 92 f3 fb 49 24 5e 94 a2 5c 3f 9d 53 |\t`<...I$^..\?.S|
000007c0 41 f0 65 0f 0e e1 0c 4b 73 28 4e 7b f4 33 50 52 |A.e....Ks(N{.3PR|
000007d0 eb f1 71 84 dc ab 34 63 3d e6 b3 61 ee cf cf 74 |..q...4c=..a...t|
000007e0 77 11 b8 5b 3f bf 1c c5 5c f9 95 15 f5 32 e9 71 |w..[?...\....2.q|
000007f0 49 c2 47 f0 3b 7d 1c 01 17 06 78 0e a9 ee 90 f2 |I.G.;}....x.....|
00000800


interessant ist: aber ab offset 7962624 lautet dann die Fehlermeldung - aber ich denke mal das liegt daran daß ich nicht die vollen 500GiB kopiert habe, sondern nur einen (grossen) Teil davon.


MainMachine 8e9eb1a2-3168-46d2-bccb-a3b127ca6427 # e2fsck -f -b7962624 ./test.img
e2fsck 1.42.13 (17-May-2015)
e2fsck: Der Versuch, einen Block vom Dateisystem zu lesen, endete in kurzem Lesen beim Versuch, ./test.img zu öffnen
Könnte es eine Partion der Länge Null sein?

[florian0285]

Hast Du das etwa in Zweifel gezogen? [emoji14]


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

Davon ab baue ich hin und wieder mal Problemstellungen nach und befasse mich damit.



Also img-gezogen ... aber wie erwartet:

interessant ist: aber ab offset 7962624 lautet dann die Fehlermeldung - aber ich denke mal das liegt daran daß ich nicht die vollen 500GiB kopiert habe, sondern nur einen (grossen) Teil davon.


Ich dachte du hast es jetzt vollständig kopiert?

Testdisk hatte doch beim alten Image angeschlagen. Ich würde jetzt davon ausgehen, dass du nur mit Datenrettung weiter kommst.

Im Zweifelsfall musst du ggf. damit rechnen, dass die Daten schrott sind.

[Jack_Herer]

interessant ist: aber ab offset 7962624 lautet dann die Fehlermeldung - aber ich denke mal das liegt daran daß ich nicht die vollen 500GiB kopiert habe, sondern nur einen (grossen) Teil davon.


MainMachine 8e9eb1a2-3168-46d2-bccb-a3b127ca6427 # e2fsck -f -b7962624 ./test.img
e2fsck 1.42.13 (17-May-2015)
e2fsck: Der Versuch, einen Block vom Dateisystem zu lesen, endete in kurzem Lesen beim Versuch, ./test.img zu öffnen
Könnte es eine Partion der Länge Null sein?


... Weisst du was ja mittlerweile mein - schrecklicher - Verdacht ist?

Ich hab bei der Installation ja die Platte nicht angetastet; ist ja meine Backup-Platte. Alles was Installation und System relevante Abläufe angeht, läuft ja über die interne HD.

Aber beim mount-Versuch kam eben dann trotzdem diese Fehlermeldung. Ich glaub aber das war nicht beim ersten mount - da hats noch geklappt, sondern beim dritten oder vierten Mal dann plötzlich.

Mein schrecklicher Verdacht ist ja mittlerweile daß Luks beim dechriffieren irgendeinen Murks gebaut hat; weil wenn dem so wäre, dann wären die Daten quasi nur 'verscrumbeld' in der Partition; und für mich ist das einfach die einzige logische Erklärung warum nicht nur der Superblock defekt ist, sondern warum ich auch keine Backup-Kopien davon finden kann.

Wenn dem tatsächlich so ist; dann hilft auch kein Datenrettungstool oder ähnliches mehr. Dann ist einfach alles wech.

[florian0285]

Ich würds versuchen. Kann ja nicht schaden. Kannst ja foremost einfach mal anlaufen lassen. Das sollte zumindest in kurzer Zeit irgendeine Datei finden. Wenn das der Fall ist besteht ja noch Hoffnung.



mkdir backup
cd backup
foremost -t all -i /Pfad/zu/backup.img

[Jack_Herer]

ja das werd ich machen. versuchen kann mans ja - aber mittlerweile hab ich nicht mehr viel Hoffnung ... aber jetzt lenk ich mich mal mit 'ner Gaming-Session ab. Ich hab momentan die Schnauze voll.

[florian0285]

Viel spass

[Jack_Herer]

also ich habs jetzt doch schon eine Weile laufen, aber leider fürchte ich ich habe recht:


foremost -wt all -i /media/bernhard/8e9eb1a2-3168-46d2-bccb-a3b127ca6427/test.img
Processing: /media/bernhard/8e9eb1a2-3168-46d2-bccb-a3b127ca6427/test.img
|************************************************* ************************************************** ************************************************** ************************************************** ************************************************** ************************************************** ************************************************** ************************************************** ****************************************

21137

[florian0285]

Ja denk ich so mal auch. Außer irgendwer meldet sich noch und kennt noch nen kniff.

[Jack_Herer]

Ja denk ich so mal auch. Außer irgendwer meldet sich noch und kennt noch nen kniff.

Trotzdem mal danke für die Hilfe - und den tröstenden Zuspruch.

[Newbie314]

Nachdem "Cosinus" dir drüben im Trojaner Board schon geschrieben hat dass Crosspostings unbeliebt sind hättest du zumindest hier auf das Crossposting drüben verlinken müssen. Umgekehrt hat es Cosinus ja schon getan.

Wenn du das Crossposting durchziehen willst (verstehe ich, vielleicht hat "drüben" noch jemand eine Idee) musst du dort gepostete Lösungsansätze hier wiederholen und umgekehrt. Sollte dir das zu viel Arbeit sein schreib einfach, dann mach ich hier zu.

http://www.trojaner-board.de/183956-frage-crypto-experten-daten-luks-container-wiederherstellen.html

[Jack_Herer]

Nachdem "Cosinus" dir drüben im Trojaner Board schon geschrieben hat dass Crosspostings unbeliebt sind hättest du zumindest hier auf das Crossposting drüben verlinken müssen. Umgekehrt hat es Cosinus ja schon getan.

Wenn du das Crossposting durchziehen willst (verstehe ich, vielleicht hat "drüben" noch jemand eine Idee) musst du dort gepostete Lösungsansätze hier wiederholen und umgekehrt. Sollte dir das zu viel Arbeit sein schreib einfach, dann mach ich hier zu.

http://www.trojaner-board.de/183956-frage-crypto-experten-daten-luks-container-wiederherstellen.html

Sorry, ich war gestern einfach nicht mehr online - hab dann noch gesucht ob es noch relevante log-files vom setup gibt. Aber dann ist mir eingefallen: Ich hab ja nachdem dem setup noch die Platte ansprechen können. Demnach findet sich auch in den log-files nichts relevantes.

Und ich weiß dass cross-postings nicht gerade die feine Art sind: Aber ich hab die Beiträge gelesen über die Verschlüsselungs-Trojaner und dass es Tools bzw. Lösungansätze gibt die auf diese Art ungewollten Daten wieder zu dechriffieren. Deshalb hab ich gedacht ich wende mich mit der Frage noch mal an die.

Aber ich seh ein daß meine Daten wohl weg sind. Was schmerzt. Es war zwar nichts sonderlich Bedeutendes auf der Platte. Aber zum Teil noch digitalisierte Videos aus den 70ern. Also der Verlust schmerzt schon.

Ich denk ich kann allgemein abschließen: eine mit einem 512er Schlüssel chiffrierte Platte wieder zu rekunstroieren ist wohl sowas wie eine Lebensaufgabe. :(