ext4 Dateisystemreste mit Testdisk

552
pathfinder

Um es auf den Punkt zu bringen: testdisk kann im Dateisystem und in der Hierarchie navigieren (scheinbar als wäre es intakt gewesen) und Dateien einzeln wiederherstellen. Gibt es eine Möglichkeit, sie alle automatisch erledigen zu lassen?

Die Geschichte:

Ich arbeite an einem DD-Klon eines unveränderlichen gddrescue-Klons (Sektor-zu-Sektor-Kopie) eines flockigen externen USB-3-TB-Laufwerks, das auf einem ~ 2016-rPI bis Oktober 2017 verwendet wird. Ich glaube, er enthielt 2 Partitionen: 6 GB und ~ 3 TB (??). ). Die 6 GB wurden wiederhergestellt und bereitgestellt. Beim Klonen konnte ddrescue nicht ~ 1 MB (insgesamt) über 25 Bereiche des Laufwerks kratzen.

Mein Ziel ist es, so viel Zeit wie möglich für die Organisation, die Dateien und die Änderungszeit großer Partitionsdateien zu retten. Vor allem wurde verwendet, verliert jedoch die Organisation (den Großteil des Wertes).

Ich arbeite jetzt mit Ubuntu 16.04.03LTS, die unveränderliche Klonpartitionstabelle hat die falschen Grenzen und ich habe testdisk verwendet, um eine plausible auf das Wiederherstellungslaufwerk zu schreiben - und das Dateisystem der ersten kleinen Partition wiederhergestellt. Interessanterweise meldet fdisk den Drivelabel-Typ als DOS und erwähnt ein Limit (2 ^ 32 Sektoren?), Und die große, von testdisk geschriebene Partition wird nur als 2 TB angezeigt. Mit parted habe ich es in GPT geändert und jetzt sind es ~ 3 TB als ~ 5.86Gsectors.

Das Dateisystem der zweiten Partition kann mit Testdesk navigiert werden, und ich kann Dateien einzeln speichern. Es gibt aber wahrscheinlich mehr als eine Million.

Die Frage: Dies sagt mir, dass ein Teil des Dateisystems vorhanden und teilweise intakt ist - aber ich weiß nicht, wie man testdisk verwendet, um die Dateistruktur und die vorhandenen Dateien automatisch zu erfassen.

Kann testdisk das tun? Oder gibt es ein anderes Werkzeug, das das Dateisystem nutzen kann? Möglicherweise das Hinzufügen von Code zu testdisk, um dies automatisch durchzuführen, ist dies ein vernünftiger Ansatz?

Ein anderer Ansatz: Nach dem "Fixieren" der Partitionstabelle mit testdisk meldet e2fsck auf Partition 2 (~ 3TB):

"" Die Dateisystemgröße (laut Superblock) beträgt 730993525 Blöcke. Die physische Größe des Geräts beträgt 536870911 Blöcke. Entweder ist der Superblock oder die Partitionstabelle wahrscheinlich beschädigt! ""

Wenn Sie mke2fs -S gefolgt von e2fsck ausführen, führt dies zu Fehlern und führt zu keinerlei Wert.

Es ist wahrscheinlich, dass im Oktober 2017 mke2fs -s auf der 2. Partition ausgeführt wurde, aber die ursprüngliche beschädigte Partitionstabelle verwendet wurde.

Ein dritter Ansatz: Testdisk ist für mich ziemlich undurchsichtig, also habe ich ein Programm geschrieben, um Superblöcke zu finden, und habe ihren letzten Einhängepunkt überprüft. Usw. Ich bin zuversichtlich, dass das Laufwerk intakte Superblöcke von der großen Partition enthält. Wenn ich eines dieser Superblöcke habe, könnte ich es irgendwie nutzen, so dass e2fsck den Rest erledigen könnte? Ich stelle mir vor, dass der Superblock jedoch nur eine Blockadresse relativ zum Start der Partition haben würde. Da sich der Superblock an einer von mehreren Stellen befinden musste (und ein bekanntes Ausblendmuster hat), könnte ich diese Informationen verwenden, um den richtigen Start der Partitionsposition zuzuweisen?

TIA!

2

1 Antwort auf die Frage

0
Xen2050

Du suchst e2fsckmit den von testdisk entdeckten Superblöcken? Unter >[ Advanced ] Filesystem Utilsdem >[Superblock]Befehl sollte "Backup Superblock Ext2 / Ext3 / Ext4 suchen" ähnlich wie folgt aussehen :

TestDisk 7.0, Data Recovery Utility, April 2015 Christophe GRENIER <grenier@cgsecurity.org> http://www.cgsecurity.org  Disk 1 - 104 MB / 100 MiB - CHS 13 255 63  Partition Start End Size in sectors  ext2 0 0 1 12 190 50 204800 superblock 0, blocksize=1024 [] superblock 8193, blocksize=1024 [] superblock 24577, blocksize=1024 [] superblock 40961, blocksize=1024 [] superblock 57345, blocksize=1024 [] superblock 73729, blocksize=1024 []  To repair the filesystem using alternate superblock, run fsck.ext2 -p -b superblock -B blocksize device   >[ Quit ] Return to Advanced menu

Versuchen Sie dann den vorgeschlagenen Befehl fsck.ext2 / e2fsck mit verschiedenen Superblöcken, bis Sie einen "guten" finden.

Testdisk scheint auch in der Lage zu sein, komplette Ordner zu kopieren. Wenn also viele Dateisysteme noch vorhanden sind, müssen möglicherweise nur die Ordner im Stammverzeichnis manuell kopiert werden, und alle ihre Unterordner und Dateien werden ebenfalls kopiert.

Hoffentlich gibt es in root nur ein paar und nicht Millionen, obwohl das :Auswählen von Dateien für das spätere Kopieren zur nächsten Datei führt und aalle Dateien (in diesem Ordner) auswählt.

Hier ist ein "Screenshot" gleich nach dem Kopieren des "Downloads" -Ordners aus dem Stammverzeichnis (er enthält 2 Dateien und die Copy done! 2 ok, 0 failedNachricht ist grün):

TestDisk 7.0, Data Recovery Utility, April 2015 Christophe GRENIER <grenier@cgsecurity.org> http://www.cgsecurity.org P ext2 0 0 1 12 190 50 204800 Directory / Copy done! 2 ok, 0 failed drwxr-xr-x 0 0 1024 17-Jan-2018 07:50 . drwxr-xr-x 0 0 1024 17-Jan-2018 07:50 .. drwx------ 0 0 12288 17-Jan-2018 07:49 lost+found drwxr-xr-x 0 0 1024 17-Jan-2018 07:50 Documents >drwxr-xr-x 0 0 1024 17-Jan-2018 07:50 Downloads    Next Use Right to change directory, h to hide deleted files q to quit, : to select the current file, a to select all files C to copy the selected files, c to copy the current file
Wow - Ich habe wirklich die Fähigkeit übersehen, Verzeichnisbäume zu kopieren. Es läuft jetzt. Root hat <10 Verzeichnisse - daher könnte dies die Lösung sein. Testdisk findet keine Superblöcke in der großen Partition. Mein Programm ist viel lockerer in Bezug auf das, was es Superblock nennt. (16-Bit-Magic-Nummer @ 0x38 und 0 Nullen bei 0x19?). Anschließend werden die Textfelder gedruckt. Aber ich denke, die einfache Verzeichniskopie wird alles tun, was ich brauche. Der erste Baum, den ich kopiert habe, hat> 150.000 Dateien, die vor allem gefunden wurden, und testdisk hat 6551 in Ordnung, wobei 0 fehlschlägt. Vielen Dank. pathfinder vor 6 Jahren 0
Es ist zu schade, dass fsck es nicht in eine gute Form bringen konnte, um es zu mounten. Xen2050 vor 6 Jahren 0

Verwandte Probleme