Ich gehe davon aus, dass die Partitionstabelle und die Boot-Partition einfach neu erstellt werden können, also werde ich mich auf die ext4-Partition konzentrieren.
Das Layout des Dateisystems hängt etwas von den Optionen ab, die bei der Erstellung verwendet wurden. Ich beschreibe den üblichen Fall. Sie können sehen, ob dies mit Ihrem übereinstimmt, indem Sie dumpe2fs ausführen auf dem Gerät (das hoffentlich alle Metadaten der obersten Ebene im Cache findet, anstatt von der Festplatte zu lesen).
Die normale Blockgröße für ext4-Dateisysteme beträgt 4096 Bytes, Sie haben also 1024 Blöcke verloren.
Das erste, was überschrieben wurde, war Block 0, der primäre Superblock. Dies ist an sich kein Problem, da Backup-Superblöcke vorhanden sind. Danach folgt die Gruppendeskriptortabelle, die auch Sicherungen im Dateisystem enthält.
Dann gibt es Block-Bitmaps und Inode-Bitmaps. Hier beginnen die Nachrichten etwas schlechter zu werden. Wenn sich einer davon unterhalb von Block 1024 befindet, was wahrscheinlich der Fall ist, haben Sie Informationen darüber verloren, welche Inodes und Blöcke verwendet werden. Diese Informationen sind redundant und werden von fsck basierend auf dem rekonstruiert, was es beim Durchlaufen aller Verzeichnisse und Inodes findet, sofern diese intakt sind.
Aber das nächste ist die Inodentabelle, und hier haben Sie wahrscheinlich viele Inodes verloren, einschließlich des Stammverzeichnisses, des Journals und anderer spezieller Inodes. Es wird schön sein, diese zurück zu haben. Offensichtlich ist zumindest das Root-Verzeichnis noch funktionsfähig, oder fast alle Befehle, die Sie auszuführen versuchen, würden bereits fehlschlagen.
Wenn Sie eine dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024 ausführen Jetzt erhalten Sie eine Sicherungskopie dessen, was sich gerade in Ihrem Cache befindet, gemischt mit den fehlerhaften Daten für die Blöcke, die nicht zwischengespeichert werden. Dann können Sie nach dem Booten einer Rettungsdiskette dasselbe tun dd Umgekehrt, um diese teilweise guten Daten wieder auf die Festplatte zu legen und das völlig schlechte Zeug zu überschreiben, das jetzt dort ist.
Danach finden Sie möglicherweise automatisierte Wiederherstellungstools (fsck , testdisk ) funktionieren gut genug. Wenn nicht, haben Sie eine Karte, die Sie bei der manuellen Wiederherstellung verwenden können. Verwenden der "freien Block"-Listen von dumpe2fs , wissen Sie, welche Blöcke Sie ignorieren müssen.
Das meiste, was Sie verloren haben, sind wahrscheinlich Inodes. Es ist tatsächlich ziemlich wahrscheinlich, dass Sie keine Datei Inhalte hatten in den ersten 4 MB der Festplatte. (Ich habe mkfs.ext4 ausgeführt ohne Optionen in einer 1-TB-Bilddatei, und der erste Nicht-Metdata-Block stellte sich als Block 9249 heraus)
Jeder Inode, den Sie wiederherstellen können, identifiziert die Datenblöcke einer ganzen Datei. Und diese Datenblöcke befinden sich möglicherweise überall auf der Festplatte, nicht unbedingt in der Nähe.
Tag 2
Der auf Pastebin gepostete Dump enthüllt großartige Neuigkeiten:
Group 0: (Blocks 0-32767) csum 0x9569 [ITABLE_ZEROED]
Primary superblock at 0, Group descriptors at 1-117
Reserved GDT blocks at 118-1141
Block bitmap at 1142 (+1142)
Inode bitmap at 1158 (+1158)
Inode table at 1174-1685 (+1174)
21349 free blocks, 8177 free inodes, 2 directories, 8177 unused inodes
Free blocks: 11419-32767
Free inodes: 16-8192
Da wir denken, dass nur 4 MB am Anfang des Dateisystems überschrieben wurden, brauchen wir uns nur um die Blöcke 0-1023 zu kümmern. Und die reservierten GDT-Blöcke gehen bis zum Block 1141! Dies ist die Art von Schäden, die mit einem einfachen e2fsck -b $backup_superblock_number repariert werden sollten (nach einem Neustart). Das könntest du zumindest mit -n versuchen um zu sehen, was es denkt.