• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Eingeschränkter Zugriff auf FP - Daten teilweise verschwunde

Phoenix7

Hacker
Hallo zusammen,

folgendes hat sich bei mir ereignet. Meine Festplatte ist vor einigen Wochen - im wahrsten Sinne des Wortes - abgefackelt. Darauf hin habe ich die Platine klonen lassen und nun habe ich zumindest wieder eingeschränkten Zugriff auf (manche Daten). Die Platte hatte ich in eine Windows XP-Partition unterteilt und in eine Linux Suse 12.1 Partition (Home, native, swap). Die Home-Daten hätte ich gerne wieder! :schockiert:

Unter dem Dateimanager wird die Platte angezeigt. Beim Zugriffsversuch bekomme ich die Fehlermeldung: "Der Kernel-Teiber für dieses Dateisystem ist nicht verfügbar. Error mounting: mount: wrongs fs type, bad option, bad superblocks on/dev/sdd4, missing codepage or helper programm, or other error. In some cases useful info is found in syslog - try dmesg | tail or so"

Code:
[  635.216136] JBD: no valid journal superblock found
[  635.216140] EXT3-fs (sdd4): error loading journal
[  641.181616] JBD: no valid journal superblock found
[  641.181620] EXT3-fs (sdd4): error loading journal
[  667.128918] JBD: no valid journal superblock found
[  667.128927] EXT3-fs (sdd4): error loading journal
[ 1776.845954] JBD: no valid journal superblock found
[ 1776.845961] EXT3-fs (sdd4): error loading journal
[ 1843.318598] JBD: no valid journal superblock found
[ 1843.318604] EXT3-fs (sdd4): error loading journal

Probiert habe ich bisher "TestDisk, Data Recovery". Dieses Programm hat zwar einige nicht Sektoren gefunden, die anscheinend im MBR nicht mehr gelistet waren aber den MBR konnte ich z.B. dann auch nicht auf die HD schreiben.

Hat jemand von Euch Rat? Wie komme ich wieder an meine Daten? :???:

Suse Linux 12.2 (Tumbleweed)
KDE 4.8.3
Kernel 3.6.6.11.1

lieben Dank & viele Grüße,
 

Jägerschlürfer

Moderator
Teammitglied
Phoenix7 schrieb:
Hat jemand von Euch Rat? Wie komme ich wieder an meine Daten? :???:
indem du ein Backup einspielst,... Es ist immer gut, sowas zu haben. Solltest du keines haben kannst du evtl noch photorec testen. Sollte das aber auch nicht funktionieren bleibt eigentlich nur noch eine professionelle Datenrettung die schnell teuer werden kann, oder man verzichtet auf die Daten und lernt daraus.
Wie heisst es so schön? Backup bringt Extraleben.
 

spoensche

Moderator
Teammitglied
Was heisst abgefakelt? Abgebrannt oder in Flammen? Statt ziellose Operationen auf der Platte auszuführen solltest du dir ein Image von der Platte erstellen und auf dem Image arbeiten.So verhinderst du das du die Platte bei den Rettungsversuchen zerstörst.

Um was für Daten handelt es sich, die du wieder herstellen willst? Sieh dir mal Photorec, sleuthkit, foremost etc. an.
 
OP
P

Phoenix7

Hacker
@spoensche
DIe Platine hat gequalmt und ist dann geklont worden. Die Daten sind unterschiedlich: Bewerbungsunterlagen, Fotos, pdfs, ...

Mittlerweile habe ich die Platte an USB und ich habe versucht Teile davon auf eine andere Platte zu sichern. Sollte ich versuchen ein Image zu machen? Bringt das überhaupt etwas, wenn die Daten auf der Platte zerstreut sind?

Die Programme schaue ich mir mal an. Vielen Dank für die Tipps!
 
A

Anonymous

Gast
Phoenix7 schrieb:
Code:
[  635.216136] JBD: no valid journal superblock found
[  635.216140] EXT3-fs (sdd4): error loading journal
wenn das die einzigen und ursprünglichen Fehler gewesen wären, dann könnte das Dateisystem mit der Mountoptionen "noload" und zusätzlich "ro" auch ohne das einhängen des Journals gemountet werden.
Allerdings ist in solchen Fällen fraglich ob das der primäre Fehler auch wirklich gewesen ist. Oftmals ist ein fehlerhafter Bereich in den ersten Inodetabellenblöcken der Grund für diese Fehlermeldung. Solange der Dateisystemsuperblock (bzw eine intakte Kopie davon) noch gefunden wird, könnte fsck sowas reparieren. Im dümmsten Fall sind dann allerdings Alles bzw. Teile des Dateisystems in lost+found zu finden.

Das ist aber in deinem Fall Theorie die dir nicht weiterhilft, da der Fehler bei dir wo anders liegt.
Wenn die Platine auf der Platte gewechselt worden ist, dann kannst du davon ausgehen das die Reihenfolge der Blöcke an verschiedenen Stellen nicht mehr stimmt. Jede Platte hat schon bei der Herstellung einige 100 bis einige Tausend physikalische Blöcke die defekt sind und für die Reserverblöcke benutzt werden. (ganz früher als die Platten noch viel weniger Kapazität hatten waren diese Tabelle sogar auf die Platte aufgedruckt) Während der Nutzungsdauer der Platte kommen eventuell noch hunderte weitere solche defekten Blöcke hinzu. Welche Blöcke das im Einzelnen sind und welches die dafür verwendeten Reserveblöcke sind, ist soweit mir bekannt ist abgelegt auf der Platine und wird von dort automatisch verwendet. Eventuell existiert auch eine Kopie davon auf der Platten, aber diese musst erstmal von der Platte ausgelesen und in die Platine geschrieben werden. Ich muss hier auch mutmaßen, da ich auch kein Spezialist aus einem Datenwiederherstellungs Labor bin, möglich das passiert mittels spezielle Firmware. Das Tauschen der Platine ist jedenfalls was für Spezialisten und nicht für Laien.

Hast du eine Platine aus einer anderen Platte verwendet, dann ist diese Tabelle jetzt falsch (und zwar doppelt falsch da die original defekten Blöcke der Platte nicht bekannt sind und du zusätzlich auch noch defekte Blöcke berücksichtigst, die aber auf einer anderen Platte aufgefallen sind) und du hast mehr oder weniger viele falsche Blöcke und damit entsprechend kaputte Dateien oder defekte Filesystemmetadaten. Hast du eine spezielle vom Hersteller dafür vorgesehene jungfräuliche Platine für deine Platte käuflich erworben, stand dort mit Sicherheit "FOR BACKUP ONLY" oder ähnliches drauf, ist wahrscheinlich, dass dort dann eine entsprechende FW drauf ist die solche Daten in diesem Falle von Platte automatisch ausliest und auf die Platine schreibt. Durchaus auch möglich, das dort erst ein spezieller Befehl dafür an die Platte gesendet werden muss, die einzelnen Plattenhersteller könnten da durchaus auch alle ganz unterschiedliche Wege gehen. Aber das ist kein Thema für dieses Forum, hier kennt sich meines Wissens auch niemand damit aus.

Ansonsten bleibt dir, defekte Dateien per Handarbeit reparieren, sind wie bei dir Fehler auch in der Dateisturktur zu finden, viel Spaß beim basteln, das ist dann ein Puzzle mit ein paar Millionen Teilen. :D

robi
 
OP
P

Phoenix7

Hacker
@robi: Danke für Deine Antwort und die Hinweise. Ich habe die Platine - wie oben beschrieben - klonen lassen und die original Firmware der alten Platte auf die neue aufspielen/brennen lassen.

TestDisk findet einige Partitionen auf der Platte (eigentlich alle) - aber manche sind eben zerstückelt. Ich suche ein Programm, dass auch ext3 Partitionen wieder reparieren kann. Mit TestDisk, Photorec, sleuthkit und foremost bin ich leider nicht weitergekommen, ...

Hast du vielleicht noch eine Idee?

Herzliche Grüße,
 
A

Anonymous

Gast
Phoenix7 schrieb:
TestDisk findet einige Partitionen auf der Platte (eigentlich alle) - aber manche sind eben zerstückelt.
Was meist du mit zerstückelt? Hast du da mal einen Printout von dem was TestDisk findet. TestDisk sucht nach Blöcken die Fragmente einer Partitionstabelle sein könnten oder aussehen wie ein Partitionsanfang. Sind auf der Platte aber zum Beispiel mal Images von anderen Platten, USB-Sticks, Disketten oder von Partitionen drauf gewesen, oder ist die Platte mal im größerem Umfang umpartitioniert worden, dann bringt das TestDisk machmal ins schleudern, da eventuell auch solche Blöcke gefunden werden. Mit den Wissen das du von der vorher dort für eine "in etwa Partitionierung" gewesen sein könnte, sollten sich solche gefundenen unlogischen Eintrage aber meist manuell richtig ausschließen lassen.

ext3 reparieren? Du brauchst mindestens den richtigen Block vom Beginn der Partition. Wenn die Partitionstabelle im MBR natürlich schon nen Treffer hat bis du dort auf wohl auf die Ergebnisse von Testdisk angewiesen.
Auf alle Fälle alle Versuche nur an einem Image von der Platte unternehmen und die original Platte nur zum erzeugen eines neuen Images benutzen, wenn du ein neues für weitere Versuche brauchst. Ob sich Testdisk auf das Image ansetzten läßt, ist mir nicht bekannt. notfalls das Image auf einen Loop legen und dann Testdisk aufs /dev/loop? loslassen. Wenn du eine eventuell richtigen Wert für den Beginn deiner ext3 Partition hast, dann diesen Partitionsanfang auf ein anderes Loop legen. Dafür musst du bei "losetup" einen Offset angeben.
Der Offsetwert ist der Startwert der "fdisk -lu" anzeigt x 512
Code:
losetup -f IMAGE -o OFFSETWERT
Dann kannst du die Partition mit dem ext3 ausprobieren durch versuchen das loopdevice das er sich dabei geschnappt hat zu mounten.
Geht das nicht solltest du erstmal schauen ob das wirklich der richtige Partitionsanfang ist. dazu kannst du zB folgendes Script benutzen. Dieses sucht nach den Backups der Superblöcke im Filesystem (anstatt LOOPDEV setzt du dort das richtige /dev/loop? Device ein)
Code:
typeset -i BLK BLK_SZ GROUP

   for BLK_SZ in 1024 2048 4096
      do
      for GROUP in 1 3 5 7 9 25 27 49 81 125 243 343 729 2187 2401 3125
         do
         BLK="$BLK_SZ"*8*"$GROUP"
         if [ $BLK_SZ -eq 1024 ]
           then BLK="$BLK"+1
         fi
         dumpe2fs -h -o blocksize="$BLK_SZ" -o superblock="$BLK"  LOOPDEV  2>/dev/null | grep UUID &>/dev/null && echo " $BLK_SZ , $BLK"
      done
   done
Bei einem richtigem Partitionsanfang solltest du eine Liste in der Art wie folgt bekommen.
4096 , 32768
4096 , 98304
4096 , 163840
4096 , 229376
4096 , 294912
4096 , 819200
4096 , 884736
4096 , 1605632
4096 , 2654208
4096 , 4096000
Der erste Wert ist die Blockgröße die sollte überall in der Liste gleich sein und der 2. Wert ist der Filesystemblock mit dem Backup vom Superblock.

Reparieren eines solchen ext3 Filesystems. Eines vorneweg, kein Tool rechnet damit das sich eventuell größere Mengen von Blöcke komplett falsch sind oder das Dateisystem eventuell umgestückelt ist.

du kannst es mit fsck auf das loopdevice versuchen, am Besten gleich auf eine Superblockkopie, die Werte die du benutzen kannst, hast du ja oben schon alle ermittelt. Das wird aber das Filesystem und damit deine Kopie von der Platte gleich verändern, und du danach für weitere Versuche ein neues Image erstellen musst. Bei ähnlich gelagerten Fällen hat das bei mir aber nicht funktioniert, also nichts wirklich gebracht.


Du kannst auch ext4magic ausprobieren, ( das verändert am Image nichts). Bei Suse 12.1 oÄ. kannst du dich hier bedienen.
Wenn du selbst kopilieren musst, dann bei configure die Option "--enable-expert-mode" setzen. Der Befehl den du benutzen müsstest
Code:
ext4magic "/dev/loop?" -s 4096 -n 4096000 -c -D -d /RECOVERDIR
/dev/loop? ist dein Loopdevice vom ext3
-s und -n sind Werte von Superblockbackups (siehe oben)
und RECOVERDIR ist ein Verzeichnis auf deinem Rechner das Platz genug hätte um alle Dateien des ext3-Filesystem zu speichern.

Hierbei wird versucht eine Kopie der Dateien des Dateisystems zu erstellen und es werden dabei unlogische oder vollkommen falsche Blöcke in den Metadaten des Dateisystems ignoriert oder stattdessen Kopien solcher Blöcke aus dem Journal verwendet. Diese Option ist aber optimiert für "starke Normaldefekte" und teilweise (bis max 25%) sequentiell überschriebene Filesysteme (also zb mit dd den Anfang oder zusammenhängende Teile innerhalb des Dateisystems mit NULLen oder mit Zufallszahlen überschrieben) und berücksichtigt in keinster Weise die mögliche Blockproblematik die bei dir anliegen könnte.

Wieviel Hoffnung du dir machen kannst? Sei mal nicht allzu optimistisch.

robi
 
OP
P

Phoenix7

Hacker
Hallo Robi,

herzlichen Dank für Deine ausführtliche Antwort. Anbei der Printout aus TestDisk.

Code:
TestDisk 6.12, Data Recovery Utility, May 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdd - 2000 GB / 1863 GiB - CHS 30401 255 63
     Partition               Start        End    Size in sectors
>D Linux                    0   4  5  2868  92 40   46080000 [Linux native]
 D Linux                 1406  44 47  4274 133 19   46080000 [Linux native]
 D Linux                 1406  97 36  4274 186  8   46080000 [Linux native]
 D Linux                 1406 117 56  4274 206 28   46080000 [Linux native]
 D Linux                 1407  17 19  4275 105 54   46080000 [Linux native]
 D HPFS - NTFS           2868  92 41  6692 210 46   61440000 [Windows E]
 D HPFS - NTFS           2868  92 41  6692 210 47   61440000
 D Linux                 6756 144 45 30400  41 41  379834368 [home]
 D Linux                 7083   0 22 30400   1  1  374587648

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 Large file Sparse superblock, 188 GB / 175 GiB

Kannst du damit etwas anfangen?

Danke Dir & viele Grüße,
 
A

Anonymous

Gast
3 Partitionen ergeben hintereinander einen Sinn eine kleine Partition dazwischen hat er nicht gesehen (bzw es könnte auch einen Zwischenraum dort gewesen sein ) wahrscheinlich jedoch der Swap. Wie es aussieht hat sich hier testdisk von Kopien des Superblocks der ersten und 4 Partition in den Daten des Filesystem Journals irritieren lassen und sich zusammengereimt, dort könnte eine Partition beginnen. Aber dem ist nicht so. diese Angaben sind mit Sicherheit Schrott. Warum die Windows Partition 2 Mal gefunden hat, kann ich nicht sagen, ich würde im Zweifelsfall die größere der beiden bevorzugen, das ist der 2. diesbezügliche Eintrag.

>D Linux 0 4 5 2868 92 40 46080000 [Linux native]
D Linux 1406 44 47 4274 133 19 46080000 [Linux native]
D Linux 1406 97 36 4274 186 8 46080000 [Linux native]
D Linux 1406 117 56 4274 206 28 46080000 [Linux native]
D Linux 1407 17 19 4275 105 54 46080000 [Linux native]
D HPFS - NTFS 2868 92 41 6692 210 46 61440000 [Windows E]
D HPFS - NTFS 2868 92 41 6692 210 47 61440000
D Linux 6756 144 45 30400 41 41 379834368 [home]
D Linux 7083 0 22 30400 1 1 374587648

Der Rest ist also wahrscheinlich mehr oder weniger Schrott oder Fehlalarm ausgelöst wahrscheinlich durch Kopien der Superblöcke in Journaldaten. Am Anfang hast du doch aber geschrieben das du die Partitionen hattest :schockiert: da gab es doch ein /dev/sdd4, also auch eine gültige Patitionstabelle. Kaputt repariert oder was hast du damit gemacht ?

So wie ich dich verstanden habe brauchst du eh nur die Dateien von Home, oder?

Also Kopie von der Platte anfertigen, bei dieser Größe ist ein Image wohl unpraktisch, also gleich eine komplette Kopie auf eine andere gleichgroße oder größere Platte anfertigen.
Dann mit testdisk auf diese Kopie losgehen, (nicht auf die Orginalplatte) und nur die home Partition wieder herstellen lassen und dann kannst du versuchen diese zu reparieren oder zu mounten, oder was auch immer. Ein LVM hattest du ja nicht auch noch dort unter dem Filesystem angelegt, oder ?
Leider ist diese Ausgabe von testdisk in Sektoren angegeben und nicht in Blöcken, sonst könnte man schon vorher mal mit dd nachschauen ob der ext3Superblock 1024 Byte hinter dem Paritionsanfang beginnt, den testdisk glaubt gefunden zu haben. Beispiel
Code:
# hexdump -C /dev/sda3 | more
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  60 8a 15 00 c6 02 56 00  f0 4c 04 00 89 a9 1a 00  |`.....V..L......|
00000410  01 3e 11 00 00 00 00 00  02 00 00 00 02 00 00 00  |.>..............|
00000420  00 80 00 00 00 80 00 00  e0 1f 00 00 e2 01 ad 50  |...............P|
00000430  e2 01 ad 50 e8 01 ff ff  53 ef 01 00 01 00 00 00  |...P....S.......|
00000440  d4 ba fb 4d 00 00 00 00  00 00 00 00 01 00 00 00  |...M............|
0x438 Byte hinter dem Partitionsanfang muss 53 ef stehen, dann ist der Partitionsanfang richtig. Das ist die Magische Zahl aus dem ext2/3/4 Filesystemsuperblock, die muss genau an dieser Stelle stehen.

robi
 
Oben