[erledigt] Daten von Festplatte retten

[Exxter]

Hallo,

ich habe eine 1TB Festplatte, auf der ein Linux installiert war/ist und möchte die Daten darauf retten.

Laut Benutzer ist sein PC eingefroren, er konnte ihn nur noch ausschalten. Danach bootete Linux nicht mehr, es kam "error: unkown filesystem".
Der User hat versucht, mit diesem Tool: https://www.chip.de/downloads/Boot-Repa ... 58348.html
den PC wieder startfähig zu machen, ohne Erfolg.

Ich habe erstmal grml gebootet und mir die Platte angesehen (sdc ist der USB-Stick auf dem grml installiert ist):

Code: Alles auswählen

root@grml ~ # fdisk -l|less
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Hitachi HDT72101
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: 0x44d4ba69

Device     Boot Start        End    Sectors   Size Id Type
/dev/sda1  *     2048 1953523711 1953521664 931.5G 83 Linux


Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Hitachi HDT72101
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: 0x44d4ba69

Device     Boot Start        End    Sectors   Size Id Type
/dev/sdb1  *     2048 1953523711 1953521664 931.5G 83 Linux                     |
                                                                                |
                                                                                |
Disk /dev/sdc: 14.7 GiB, 15720251392 bytes, 30703616 sectors                    |
Disk model: DT Rubber 3.0                                                       |
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: 0x0133b4c4                                                     |
                                                                                |
Device     Boot Start      End  Sectors  Size Id Type                           |
/dev/sdc1  *     2048 30703615 30701568 14.7G  c W95 FAT32 (LBA)                |
                                                                                |
                                                                                |
Disk /dev/loop0: 618 MiB, 647962624 bytes, 1265552 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    

Die Platte ist laut Smart-Werte OK. Ich habe eine identische zweite Platte angeschlossen und über Nacht mit dd eine Kopie erstellt:

Code: Alles auswählen

root@grml ~ # dd if=/dev/sdb of=/dev/sda bs=8M                                  |
119233+1 records in                                                             |
119233+1 records out                                                            |
1000204886016 bytes (1.0 TB, 932 GiB) copied, 11315.2 s, 88.4 MB/s              |
dd if=/dev/sdb of=/dev/sda bs=8M  1.01s user 2125.77s system 18% cpu 3:08:35.19 |
total                                                                           |
root@grml ~ #   

Das Problem ist, wenn ich die Partition mounten will, kommt:

Code: Alles auswählen

root@grml ~ # mount /dev/sdb1 /mnt                                              |
NTFS signature is missing.
Failed to mount '/dev/sdb1': Invalid argument
The device '/dev/sdb1' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
12 root@grml ~ #     

Bzw. wenn ich das korrekte FS angebe:

Code: Alles auswählen

root@grml ~ # mount /dev/sdb1 /mnt -t ext4
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sdb1, missing cod|
epage or helper program, or other error.
32 root@grml ~ #   

Hat jemand eine Idee, was ich hier noch machen kann?
Scheinbar hat dieses Tool oben irgendwas am Dateisystem gemacht, das ist leider nicht mehr nachvollziehbar.
Noch eine wichtige Info, laut User hat er das Linux ohne Swap installiert, deswegen gibt es nur eine große Partition.

[debianoli]

Lass mal testdisk ran

[Exxter]

OK, bin auf "Analyse":

Code: Alles auswählen

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

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

No ext2, JFS, Reiser, cramfs or XFS marker
 1 * Linux                    0  32 33 121601  57 56 1953521664
 1 * Linux                    0  32 33 121601  57 56 1953521664







*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted
>[Quick Search]  [ Backup ]
                            Try to locate partition

Im nächsten Bild:

Code: Alles auswählen

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

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
     Partition               Start        End    Size in sectors
>* Linux                    0  32 33 121601  57 56 1953521664





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 Backup_SB, 1000 GB / 931 GiB

Eigentlich hat die Partition ja den richtigen Typ ext4 ?

[pferdefreund]

Wenn es nur um die Daten geht, eventuell mal photorec probieren. Damit habe ich mal die ganzen Daten eines Kollegen über einen Live-Stick retten können. Die Dateinamen gehen dabei allerdings verloren. Alternativ einfach das Backup einspielen (ach so, ist ja ein Schimpfwort und sollte nicht verwendet werden).

[debianoli]

Code: Alles auswählen

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

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

No ext2, JFS, Reiser, cramfs or XFS marker
 1 * Linux                    0  32 33 121601  57 56 1953521664
 1 * Linux                    0  32 33 121601  57 56 1953521664

Im nächsten Bild:

Code: Alles auswählen

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 Backup_SB, 1000 GB / 931 GiB

Eigentlich hat die Partition ja den richtigen Typ ext4 ?

Sieht für mich auf den ersten Blick gut aus. Du hast ja ein Image, richtig? Dann kannst du versuchen, beim Image die Partition mit Testdisk wieder herzustellen und dann einen Filecheck drüber laufen zu lassen. Mehr dazu unter https://www.cgsecurity.org/ , speziell hier https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

[hikaru]

Laut Partitions-ID sollte das ein ext-Dateisystem sein (ohne Garantie). Warum mount da mit ntfs rangeht ist rätselhaft. Vielleicht hat genau das die Rettungs-CD zerwürgt. Was passiert, wenn du versuchst, das Dateisystem explizit als ext3 bzw. ext4 zu mounten?

[debianoli]

Was passiert, wenn du versuchst, das Dateisystem explizit als ext3 bzw. ext4 zu mounten?

Wäre es nicht besser, testdisk die Partitions-Tabelle zuerst wieder schreiben zu lassen?

[MSfree]

Wäre es nicht besser, testdisk die Partitions-Tabelle zuerst wieder schreiben zu lassen?

Am allerbesten wäre es, erstmal ein Image der Platte auf eine andere Platte zu ziehen und mit der Kopie zu experimentieren, sonst besteht Gefahr, mehr kaputt zu machen, als einem lieb ist.

[debianoli]

Wäre es nicht besser, testdisk die Partitions-Tabelle zuerst wieder schreiben zu lassen?

Am allerbesten wäre es, erstmal ein Image der Platte auf eine andere Platte zu ziehen und mit der Kopie zu experimentieren, sonst besteht Gefahr, mehr kaputt zu machen, als einem lieb ist.

Hat er bereits gemacht, s.o.

[willy4711]

Hab mal ne ganz dumme Frage:

Code: Alles auswählen

root@grml ~ # fdisk -l|less
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Hitachi HDT72101
Units: sectors of 1 * 512 = 512 bytes
...
Disk identifier: 0x44d4ba69

und

Code: Alles auswählen

Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Hitachi HDT72101
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
...
Disk identifier: 0x44d4ba69

Sind das zwei Platten ? Selber Disk identifier / Festplattenbezeichner
Die Aufteilung in /dev/sda und /dev/sdb auf einem physikalischen Laufwerk wäre mir neu.
Welche ist denn die "Kaputte"?

Edit:
Du versuchst /dev/sdb1 zu mounten, untersuchst aber mit TestDisk /dev/sad

Auf welche Platte ist denn was, und was soll gerettet werden?
Es sind doch 3 Platten ?

[hikaru]

sdb ist die ursprünglich "Kaputte". Die wurde mit dd auf sda übertragen - offenbar erfolgreich.
Rettungsversuche finden jetzt mal auf sdb, mal auf sda statt. Ich vermute, Exxter hat eine Münze zur Hand.
sdc ist offenbar unbeteiligter Zuschauer.

Sinnvoll wäre tatsächlich, Rettungsversuche konsequent auf der Kopie (sda) auszuführen.

[Exxter]

Ja es sind zwei identische Festplatten per SATA angeschlossen, wobei /dev/sdb die "kaputte" ist und /dev/sda die Sicherung. Ich ging davon aus, dass mounten nicht schlimm ist, deswegen mit /dev/sdb probiert. Du hast natürlich Recht, ich sollte nur an /dev/sda probieren.

Ich habe jetzt die Partitionstabelle mit Testdisk neu auf sdb geschrieben, leider möchte er jetzt einen Reboot, den ich erst später machen kann.
Aber als ich mit "p" die Dateien anzeigen lies, sah ich eine komplette Linux-Dateistruktur, das lässt ja hoffen

[debianoli]

Ich habe jetzt die Partitionstabelle mit Testdisk neu auf sdb geschrieben, leider möchte er jetzt einen Reboot, den ich erst später machen kann.
Aber als ich mit "p" die Dateien anzeigen lies, sah ich eine komplette Linux-Dateistruktur, das lässt ja hoffen

Den Reboot braucht es zuerst nicht, eher einen Filecheck,

Code: Alles auswählen

e2fsck -f /dev/sdb1

Mounten sollte nach dem Filecheck auch kein Problem sein.

[willy4711]

sdb ist die ursprünglich "Kaputte". Die wurde mit dd auf sda übertragen - offenbar erfolgreich.

Ok war dann ein Missverständnis aufgrund dieses Satzes:

Jetzt ist der ganze PC bei mir gelandet. Ich habe erstmal grml gebootet und mir die Platte angesehen:

[Exxter]

Den Reboot braucht es zuerst nicht, eher einen Filecheck,

Code: Alles auswählen

e2fsck -f /dev/sdb1

Mounten sollte nach dem Filecheck auch kein Problem sein.

Ja! Bingo, e2fsck lief länger durch, korrigierte viel. Jetzt lässt sich sdb mounten, alle Dateien scheinen wieder da zu sein.

Vielen herzlichen Dank an euch. Jetzt wird das Thema "Backup" hoffentlich mal richtig angegangen...

[debianoli]

Laut Benutzer ist sein PC eingefroren, er konnte ihn nur noch ausschalten. Danach bootete Linux nicht mehr, es kam "error: unkown filesystem".
Der User hat versucht, mit diesem Tool: https://www.chip.de/downloads/Boot-Repa ... 58348.html
den PC wieder startfähig zu machen, ohne Erfolg.

Du solltest dem User sagen, dass neben einem Backup auch etwas Geduld hilfreich sind. Manchmal reicht es schon, ein Live-System zu starten und einen FIlecheck zu machen. Oder NACHZUFRAGEN, was denn los sein könnte. Bevor man mit irgendwelchen Tools aus dem Internet alles platt macht.