☰

Verlorene Ext4-Partition: Testdisk listet Dateien auf, kann die Partitionstabelle jedoch nicht reparieren

tag-icon • tag-icon linux ubuntu partitioning data-recovery partition-recovery
Verlorene Ext4-Partition: Testdisk listet Dateien auf, kann die Partitionstabelle jedoch nicht reparieren

Zusammenfassung:

Testdisk findet die verlorene ext4-Partition und kann die darin enthaltenen Dateien auflisten, aber der Versuch, die Partitionsstruktur auf die Festplatte zu schreiben, passiert nichts.

Aktualisieren: Nach dem Ausführen e2fsck -f /dev/sdc1wurde die Festplatte gemountet und scheint normal zu laufen. Es wurden jedoch auch einige Fehler gemeldet (siehe 15. unten).

Was ist passiert:

Ich werde versuchen, alles aufzulisten, was ich im Zusammenhang mit dem Problem getan habe:

  1. Ich habe eine neue externe 5-TB-Festplatte bekommen, die als FAT32 vorformatiert war (mit dem Namen Intenso).
  2. Ich habe diese Partition gelöscht und mit gparted eine neue ext4-Partition erstellt (mit dem Namen Intenso5TB).
  3. Da die Partition Root gehörte, habe ich Besitzer und Gruppe zu meinem Benutzer geändert.
  4. Ich habe einige Hundert GB Daten auf diese Partition verschoben und sie dann sicher entfernt.
  5. Als ich die Festplatte das nächste Mal anschloss, war sie schreibgeschützt gemountet. Mein Benutzer war immer noch der Eigentümer.
  6. Ich habe „rw“ zu den Mount-Optionen im Ubuntu-Dienstprogramm „Disks“ hinzugefügt und das Laufwerk ausgehängt.
  7. Das Dienstprogramm „Festplatten“ zeigte dann die Partition /dev/sdc1 als „Typ unbekannt“ an und sie konnte nicht gemountet werden.
  8. Ich habe "Partition bearbeiten" gewählt und "Typ Linux (0x83)" ausgewählt (kein Typ war vorab ausgewählt). Es gab keine Änderung (Typ immer noch unbekannt).

  9. Ich sudo testdisk /dev/sdchabe eine schnelle Analyse durchgeführt und Folgendes festgestellt:

    * Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]

    Durch Drücken pwerden die Dateien angezeigt, die ich auf die Partition verschoben habe., also habe ich Testdisk angewiesen, die Partitionsstruktur auf die Festplatte zu schreiben.

  10. Nach einem weiteren Neustart zum Aktualisieren der Partitionstabelle war das Verhalten wieder wie unter 7 beschrieben.

  11. Ich habe 9. neu gemacht; dieses Mal habe ich versucht,

    partprobe /dev/sdc

    um einen erneuten Neustart zu vermeiden, habe aber die Meldung erhalten:

    Error: Partition(s) 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64 on /dev/sdc have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.

  12. sudo fdisk -lukehrt zurück

    Disk /dev/sdc: 4,6 TiB, 5000981078016 bytes, 1220942646 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33550336 bytes
Disklabel type: dos
Disk identifier: 0x4400838c

Device     Boot Start        End    Sectors  Size Id Type
/dev/sdc1  *      256 1220942591 1220942336  4,6T 83 Linux

  13. Ich habe es sudo parted /dev/sdcdann ausgeführt rescue 256 1220942591, was nichts bewirkt hat (keine Verzögerung, keine Ausgabe, nur eine neue Eingabeaufforderung innerhalb von parted), dasselbe gilt für rescue 0 1220942591, rescue 1 1220942591oder rescue 1 -1.

  14. Ich habe eine gründliche Suche mit Testdisk durchgeführt, die mehrere identische Zeilen meldete:

    Linux                    0   4  5 76000  41  9 1220942336 [Intenso5TB]

    sowie:

    check_FAT: can't read FAT boot sector
Invalid FAT boot sector
 0 D FAT16 LBA            252822 192 45 254047 161 57   19677685
  FAT16 LBA            252822 192 45 254047 161 57   19677685

    während des Laufens und geschlossen mit:

    TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org

Disk /dev/sdc - 5000 GB / 4657 GiB - CHS 76000 255 63

The harddisk (5000 GB / 4657 GiB) seems too small! (< 16 TB / 15 TiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partition can't be recovered:
     Partition               Start        End    Size in sectors
>  FAT16 LBA            252822 192 45 254047 161 57   19677685










[ Continue ]
80 GB / 75 GiB

  15. Nach dem Ausführen e2fsck -f /dev/sdc1wurde die Festplatte im Launcher angezeigt. Ich habe e2fsckmit abgebrochen Ctrl+C, um weitere Änderungen zu vermeiden, bis ich mehr weiß. Das Laufwerk wurde dann per Klick erfolgreich gemountet. Ich scheine lesen und schreiben zu können. Ausgabe von e2fsck:

    e2fsck -f /dev/sdc1
e2fsck 1.42.13 (17-May-2015)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
Intenso5TB: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Inode 59883521 is in use, but has dtime set.  Fix<y>? yes
Inode 59883521 has imagic flag set.  Clear<y>? yes
Inode 59883521 has compression flag set on filesystem compression support.  Clear<y>? yes
Inode 59883521 has INDEX_FL flag set but is not a directory.
Clear HTree index<y>? yes
Inode 59883521, i_blocks is 16777216, should be 0.  Fix<y>? yes
Deleted inode 59885573 has zero dtime.  Fix<y>? yes
Deleted inode 59885574 has zero dtime.  Fix<y>? yes
^CIntenso5TB: e2fsck cancelled.

Intenso5TB: ***** FILE SYSTEM WAS MODIFIED *****

Meine Fragen:

  1. Habe ich einen offensichtlichen Fehler gemacht, der dieses Problem überhaupt erst verursacht haben könnte?

  2. Besteht Hoffnung, die verlorene Partition wiederherzustellen? Neue Frage: Sind die gemeldeten Fehler e2fsckein Grund zur Sorge? Könnten sie auf ein physisch beschädigtes Laufwerk hinweisen?

  3. Was verursacht die Fehlermeldung von partprobein 11?

(Die Daten wurden von einer anderen Festplatte verschoben, die ich seitdem nicht mehr berührt habe. Sie sind also derzeit nicht sichtbar, sollten aber von dort rettbar sein.)

Antwort1

Beim Durchlaufen e2fsck -f /dev/sdc1wurde ein fehlerhafter Superblock behoben und das Gerät wurde problemlos erkannt. Anschließend ließ ich e2fsckalle gefundenen Probleme beheben. Bei einem nachfolgenden Durchlauf e2fsckwurden keine weiteren Fehler gemeldet.

Ein erweiterter Offline-Test, der smartctlnach 9 Stunden abgeschlossen wurde und keine Fehler meldete (um zu verhindern, dass der Test durch automatisches Spindown abgebrochen wird, habe ichdiese Problemumgehung).

verwandte Informationen