Recovery einer SSD nach Stromausfall

[BBig]

Hallo zusammen, ich hoffe ihr habt noch eine Idee, denn mir sind sie ausgegangen.
Seit 4 Stunden sitze ich hier und versuche nach einem Stromausfall an die Daten von einer SSD zu kommen.

Was ich bis jetzt gemacht habe:

- Zuerste eine Kopie (*.img) der SSD mit ddrescue erstellt. Lief ohne Fehlermeldung durch.
- Check der SMART-Werte (smartctl) der SSD sehen gut aus. Nichts Auffälliges.
- fdisk sagt : "Gerät enthält keine erkennbare Partitionstabelle."
- Gparted unter Informationen : "/dev/sdd: unbekannte Partitionstabelle"

- Ok, dann an die *.img: Erst wollte ich die *.img-Datei mounten.
Konnte ich nicht, da ich nicht sicher bin, welchen offset.
parted /run/media/bbig/data_ntsf/BackUpSSD/sdb_ddrescue.img

(parted) print
Modell: (file)
Festplatte /run/media/bbig/data_ntsf/BackUpSSD/sdb_ddrescue.img: 250GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags:

Nummer Anfang Ende Größe Typ Dateisystem Flags

- e2fsck und extundelete: Wenn ich das richtig verstanden habe, funktionieren nicht, da die Kopie wie das Orginal keine Partitionstabelle aufweist.
- Oke, irgendwie muss ich wieder an Partitionen kommen -> testdisk (http://www.cgsecurity.org/wiki/TestDisk)

Quick Search findet eine Partition:

Disk /run/media/bbig/data_ntsf/BackUpSSD/sdb_ddrescue.img - 250 GB / 232 GiB - CHS 30402 255 63
Partition Start End Size in sectors
>* Linux 8923 223 5 16572 204 16 122880000 [antergos]

Unter Dateinen anzeigen (p):

* Linux 8923 223 5 16572 204 16 122880000 [antergos]
Directory /

No file found, filesystem may be damaged.


Dann weiter mit Advanced Search, eigentlich sollten da 4 Partitionen sein:

Disk /run/media/bbig/data_ntsf/BackUpSSD/sdb_ddrescue.img - 250 GB / 232 GiB - CHS 30402 255 63
Partition Start End Size in sectors
D Linux 8923 223 5 16572 204 16 122880000 [antergos]
D Linux 12600 149 30 20249 130 41 122880000 [antergos]
D Linux 12601 187 3 20250 168 14 122880000 [antergos]
>D Linux 12605 12 16 20253 248 27 122880000 [antergos]


Super, dachte ich, testdisk findet 4, aber auf allen kann ich keine Dateinen anzeigen: "No file found, filesystem may be damaged."

Wenn ich dann weiter mache und den Partitionen Typen zuordne - z.B. Bootable, Primary - dann zeigt er in rot an "Structure: Bad." und bricht beim Partitionen schreiben ab.

===

Ich weiß nicht mehr weiter.

Ich denke, die Partitionstabelle ist futsch, ich müsste also eine Neue erstellen, damit ich erstmal anfangen kann nach Dateien zu suchen.
Gibt es ein Programm, was mir dabei Werte vorschlägt?
Oder kann man aus den testdisk-Werten was machen?

Wenn ihr noch eine Idee habt, dann her damit!
Danke, Bbig

[Gast]

Also meiner Erfahrung nach erholen sich SSDs nach einem Stromausfall oft ganz von alleine.

Ich würde einfach einen Tag lang nichts machen und es dann nochmal versuchen ;)

[Account]

die start/end werte sind quatsch, da lägen mehrere partitionen ineinander. hast du die partitionen damals selbst erstellt oder den installer machen lassen? falls ersteres, wäre dein gedächtnis gefragt; falls letzteres, würde ich mal versuchen herauszufinden nach welchen regeln antergos partitionen erstellt.
ich glaube nicht, dass irgendein programm das automatisch rekonstruieren könnte.

[BBig]

Danke euch zwei!

@Gast Der Stromausfall ist nun 3 Tage her, zählt das? :D

@Account Ja, habe ich auch gesehen;
die Werte, die testdisk ausgibt machen keinen Sinn, :frown:

Ich weiß noch wie ich sie partitioniert habe:

1 - sollte eine 4 GB Swap sein
2 - 50GB ext4
3 - 50GB ext4
4 - sollte der Rest sein / ext4

Ich habe aber keine Ahnung, wie mir das weiter helfen könnte.

[Account]

an den ungefähren anfangspunkten der partitionen kannst du dann nach dem ext4 header suchen:
https://unix.stackexchange.com/questions/103919/how-do-i-find-the-offset-of-an-ext4-filesystem

[BBig]

Von Christophe Grenier gibt es neben testdisk auch noch photorec (http://www.cgsecurity.org/wiki/PhotoRec):

Das Eigenartige, photorec sucht nach Dateien ohne zu meckern, :eek:
Aber findet nur knappe 500 *.txt-Dateinen, sonst nichts, :frown:

Irgendwie habe ich das Gefühl, dass die Dateinen noch da sind, ich übersehe nur was.

an den ungefähren anfangspunkten der partitionen kannst du dann nach dem ext4 header suchen:
https://unix.stackexchange.com/questions/103919/how-do-i-find-the-offset-of-an-ext4-filesystem

Danke, da schaue ich gleich mal.

Edit:
Deinen Link verstehe ich nicht, ;(
Ich habe die Werte von testdisk für die offests ausprobiert, kommt aber immer die selbe Fehlermeldung: Z.B.

mount -t ext4 -o loop,ro,offset=8923 ./sdb_ddrescue.img /mnt/sdb_rescue/
mount: Falscher Dateisystemtyp, ungültige Optionen, der
Superblock von /dev/loop0 ist beschädigt, fehlende
Kodierungsseite oder ein anderer Fehler

Manchmal liefert das Systemprotokoll wertvolle Informationen –
versuchen Sie dmesg | tail oder ähnlich
dmesg | tail
[13718.621515] EXT4-fs (loop0): VFS: Can't find ext4 filesystem

Ich gebe auf, außer ihr habt noch eine Idee.

[sei laut]

8923 als Offset ist nicht korrekt. Was du brauchst, ist 4568576. Also 8923*512. Könnte zumindest besser gehen. Das stimmt dann auch eher mit der 4G Swap vornedran.


Oder im Zweifel dann doch brute force wie im Link beschrieben. Als Bash script abspeichern, bzw. den mount befehl anpassen.
bsz=512 # or 1024, 2048, 4096 higher = faster

for i in {2..10000000}; do
echo "--->$i<---"
mount -o offset=$(($bsz*$i)) -t ext4 /dev/whatever /mnt/foo
if [ $? == 0 ]; then # whahoo!
echo Eureka
break
fi
done

[Account]

Deinen Link verstehe ich nicht, ;(

im bereich von 4gb nach start des images suchst du nach 1024 leeren bytes. wenn 56 byte nach dem ersten nichtleeren byte 53EF kommt, setzt du den offset für das dateisystem auf das erste der 1024 leeren bytes.

ich habs auch nicht ausprobiert, aber so steht das da ;)

edit: ja oder du lässt natürlich das skript laufen, einfach mal von 8mio bis 9mio blöcke, vielleicht weiter eingrenzen, keine ahnung wie lange ein mountversuch dauert

[BBig]

Ja, das Script habe ich gesehen; habe aber nur gedacht:

Sagen wir 4 GB *swap* am Anfang der SSD; Alle 512 bytes ein Mount-Versuch, richtig?

4 gigabytes durch 512 bytes = 7812500 Mountversuche?
Bis zu den ersten 4 GB der SSD? Sprich, ich müsste so bis 8 Million Mountversuchen das Script laufen lassen? Oder ist mein Mathe arg daneben?

Hmm, wie lange das wohl dauert. Spamt das nur die Log-Dateinen zu? :freak:

[Account]

du suchst ja nur zB von 3,9gb bis 4,1gb. daher schrub ich ja einen vorschlag die grenzen der iteration einzuschränken. oder eben manuell nach dem "magic byte" suchen. und natürlich hoffen, dass die daten ok sind und auch in der reihenfolge ankamen, wie sie auf der ssd waren ;)

[BBig]

Ja, ich habe jetzt erst deinen Edit gelesen :tongue:

Ich lasse es gerade laufen:

bsz=512 # or 1024, 2048, 4096 higher = faster

for i in {7811000..10000000}; do
echo "--->$i<---"
mount -o loop,ro,offset=$(($bsz*$i)) -t ext4 ./sdd.img /mnt/sdb_rescue/
if [ $? == 0 ]; then # whahoo!
echo Eureka
break
fi
done

8M Mounts dauert viel zu lange. Deswegen hatte ich die Idee wie du und fange einfach später an. Ich bin ziemlich sicher, dass es eine 4 GB *swap* war.

===

Edit: Ich habe es bis (umgerechnet) 4,1 GB laufen lassen. Hat ca. 4 Stunden gedauert, :freak:
Leider keinen Erfolg. Aber danke für euren Input, :smile: