Wiederherstellung der ext4-Partition nach dem Start von HD

Ich habe versehentlich dddie ersten 208 MB meiner externen Festplatte verwendet und darüber geschrieben. Was ich überschrieben habe, ist eine Partition für sich (Debian nestinstaller). Was ich jetzt sehe, ist also nicht meine alte (jetzt beschädigte) ext4-Partition, sondern eine andere kleinere Partition. Dies schränkt die Werkzeuge und Ratschläge ein, denen ich folgen könnte.

Mein Plan war es, die Partitionstabelle mit neu zu erstellen testdiskund dann alles mit den hier beschriebenen Backup-Superblöcken zu reparieren . Ich würde die ersten 208 MB verlieren, aber das ist in Ordnung im Vergleich zu den anderen 300 GB Daten dort. So etwas wie das Folgende:

mke2fs -n /dev/sdb1   # doesn't work because sdb1 is the 208MB new partition
testdisk ...          # used this to create new correct partition table
mke2fs -n /dev/sdb1   # now works fine, get backup superblock positions
e2fsck -b backup_position -y /dev/sdb1 # returns many errors hence the -y

Ich konnte jedoch nichts wiederherstellen. Ich habe testdiskeine neue Partitionstabelle geschrieben, die meiner vorherigen entspricht. Wenn ich dann e2fsck starte, bekomme ich viele verschiedene Fehler. Danach bekomme ich ein Dateisystem, aber es ist komplett leer, keine Dateien.

Das Verzeichnis Lost + Found ist voll von Dateien (wiederhergestellte, glaube ich), aber ich muss den Verzeichnisbaum wiederherstellen, nicht nur die Dateien. Ich benötige den Dateinamen und die vorherigen Verzeichnisse, um zu wissen, um welche Dateien es sich handelt (Mikroskopbilder, Massenspezifikationsdaten usw. Ohne die Namen und Verzeichnisse, in denen sie sich befanden, bedeuten sie nichts).

Ich habe eine andere HD genau gleich bekommen und eine Kopie der gesamten HD mit erstellt, dddamit ich die Wiederherstellung experimentieren kann, ohne etwas zu verlieren. Irgendein Rat?

Ich habe es endlich geschafft, das zu beheben. Nur zur Veranschaulichung hier ist, wie ich es gemacht habe. Ein Teil der Lösung, die ich hier gefunden habe , besteht darin, die Einstellungen zu kennen, die zum Erstellen des Dateisystems verwendet wurden (ich war mir ziemlich sicher, dass ich die Standardeinstellungen nicht geändert habe).

Grundsätzlich musste ich zuerst die Partitionstabelle reparieren, um zu reflektieren, was ich tatsächlich dort hatte (ich habe testdiskdies aber verwendet parted, cfdiskoder fdisksollte auch gut funktionieren). Ich habe gerade die falschen Partitionen entfernt und durch eine einzelne ext4-Partition ersetzt, die die gesamte Festplatte mit den richtigen CHS-Werten abdeckt.

Der Rest ist meistens über den Link am Anfang (lesen Sie ihn für Details), aber im Grunde bin ich gelaufen mke2fs -n /dev/xxx, um die Positionen für das Superblocks-Backup zu finden. Verwenden Sie dann die letzte Sicherung, die dem Ende der Festplatte am nächsten liegt (nur die am Anfang der Festplatte wurden mit dd überschrieben), um fsck auszuführen. Dies hat viele Fehler erzeugt, aber fsck hat eine -yOption (nicht die gleiche wie -a).

$ sudo e2fsck -a -b backup_block_number /dev/xxx

Ich dachte, das hätte nicht funktioniert, weil ich keine Dateien sehen konnte, aber tatsächlich waren alle im lost+foundVerzeichnis gespeichert .

Am Ende habe ich also die meisten meiner Dateien gerettet, während ich ihre Dateinamen und Verzeichnisstruktur beibehalten habe. Hoffe, dass dies anderen in Zukunft helfen kann.

Ok, dies funktioniert für die Wiederherstellung von einem versehentlich inaktiven Laufwerk in einem MegaRAID-Array. Mein RAID-Controller hat ALLE Laufwerke im RAID aktiviert, nicht nur die für das RAID6-Array, das ich neu erstellt habe. Autsch! Zumindest habe ich eine schnelle Initialisierung durchgeführt und keine langsame Initialisierung - die langsame Initialisierung löscht das Laufwerk auf Null.

Quick Init löscht 10M am Anfang und Ende der Laufwerke. Ich hatte also mit einer ext4-Partition auf dem gesamten Laufwerk (unter Linux) und einem Laufwerk, RAID0, eine Chance. Da das Laufwerk ein 6-TB-Laufwerk ist und fast 5 TB darauf liegt, schwitzte ich - es war mein Backup des RAID6-Arrays, das ich reformierte!

Übrigens, ich bin nicht ausgerutscht - das LSI MegaRAID sollte KEINE Laufwerke in meiner anderen Laufwerksgruppe gestartet haben - aber es tat es. Als Hinweis hätte ich das Laufwerk aus dem Gehäuse entfernen und es erneut importieren sollen, nachdem ich die neu arrangierte RAID6-Laufwerksgruppe hatte. Wie dumm von mir. Wirklich dumm mich ....

OK, zum Glück macht der LSI MegaRaid mit RAID0-Laufwerken nichts Besonderes (wenn es eines gibt, bin ich mir über mehrere nicht sicher). Hier ist, was ich getan habe, um das Problem zu beheben. OS = Fedora F22. Laufwerk = eine große ext4-Partition, die mit einem Teil ausgeführt wird. Zuerst habe ich das Laufwerk auf ein brandneues Laufwerk mit genau demselben Modell in einem Ersatzserver mit ein paar Ersatzschachtsteckplätzen gedreht: Zehn Stunden später war es fertig ......

$ dd if=/dev/sdb of=/dev/sdc bs=64M conv=notrunc
89424+1 records in
89424+1 records out
6001175126016 bytes (6.0 TB) copied, 35130.2 s, 171 MB/s

Das war mein goldenes Backup.

HINWEIS - Mein Laufwerk war /dev/sdb- Sie müssen Ihr Laufwerk auf das Laufwerk einstellen, das Sie wiederherstellen möchten. Mach die Laufwerke nicht kaputt, sonst wirst du noch mehr durcheinander sein ...

Dann habe ich Folgendes getan.

(1) Entfernen Sie den Schnappschuss vom Computer (ich kann Ihnen versichern, dass dieser nicht albern ist, wenn ich versagt habe, während ich mich in die örtliche Notaufnahme eincheckte!).

(2) Starten Sie den FC22-Computer mit dem Laufwerk neu. Führen Sie parted aus, wiederholen Sie die Partition (in meinem Fall löschen Sie die beschädigte Partition, schreiben Sie eine neue 0% bis 100% ext4-Partition ein). Sie MÜSSEN genau wissen, wo sich die ursprünglichen Partitionen befanden und welchen Typ sie genau hatten - der nächste Schritt hängt davon ab - wenn nicht, STOPPEN SIE HIER. Du wirst es nicht schaffen. Verwenden Sie testdiskund photorecoder ähnlich, oder für eine große Fahrt, wo es wirklich wichtig ist, versenden Sie es aus.

(3) rennen mke2fs -n /dev/sdb1(vergiss das nicht -n, oder du kannst wieder einfach weggehen ...)

Für mich sah das Ergebnis so aus:

$ mke2fs -n /dev/sdb1
$ mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 1464843008 4k blocks and 183107584 inodes
Filesystem UUID: 1ac318a6-7953-42d5-8d7b-0597c54e1935
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

Da bist du ja, dort sind alle Ersatz-Superblöcke ... Wir wissen, dass der erste und der letzte Müll sind, aber die in der Mitte sollten in Ordnung sein. (Beachten Sie, dass Sie sehr mkfs.ext4 -n /dev/sdb1vorsichtig sein und das gleiche Ergebnis erzielen können).

(4) Ausführen e2fsck -y -b 102400000 /dev/sdb1. Sie benötigen das -y, da eine Menge "Ja" erforderlich ist, um das durch das fehlende Frontend der Festplatte verursachte Durcheinander zu beheben. Wählen Sie einen beliebigen Superblock in der Mitte aus ... und nach etwa 30 Minuten der Stille (verwenden Sie ein anderes Terminal und "oben", um den Fortschritt oder das blinkende Festplattenlicht zu verfolgen) in meinem Fall Presto, eine montierbare Partition und so ziemlich alles, was im /lost+foundVerzeichnis intakt ist .

Wie auch immer, ich hoffe das hilft - wenn Sie dies sorgfältig lesen, dann wünsche ich Ihnen viel Glück. Und danke an die Jungs, die oben geschrieben haben. Du hast mich vor einem wirklich schlimmen Ende gerettet ...