Falscher DD-Befehl auf dem Hauptlaufwerk – Wie kann ich die Daten wiederherstellen?

Question 1

Ich gehe davon aus, dass die Partitionstabelle und die Bootpartition problemlos neu erstellt werden können, daher werde ich mich auf die ext4-Partition konzentrieren.

Das Layout des Dateisystems hängt in gewissem Maße von den bei seiner Erstellung verwendeten Optionen ab. Ich beschreibe den allgemeinen Fall. Sie können sehen, ob dies Ihrem entspricht, indem Sie es dumpe2fsauf dem Gerät ausführen (wodurch hoffentlich alle Metadaten der obersten Ebene im Cache gefunden werden, 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.

Als erstes wurde Block 0 überschrieben, der primäre Superblock. Das ist an sich kein Problem, da es Backup-Superblöcke gibt. Danach folgt die Gruppendeskriptortabelle, die ebenfalls Backups innerhalb des Dateisystems enthält.

Dann gibt es Block-Bitmaps und Inode-Bitmaps. Hier werden die Neuigkeiten etwas schlechter. Wenn sich eines 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, was es beim Durchsuchen aller Verzeichnisse und Inodes findet, rekonstruiert, sofern diese intakt sind.

Als nächstes kommt jedoch die Inode-Tabelle, und hier haben Sie wahrscheinlich viele Inodes verloren, darunter das Stammverzeichnis, das Journal und andere spezielle Inodes. Es wäre schön, diese wieder zu haben. Offensichtlich ist zumindest das Stammverzeichnis noch funktionsfähig, sonst würden fast alle Befehle, die Sie ausführen möchten, bereits fehlschlagen.

Wenn Sie dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024jetzt ein ausführen, erhalten Sie eine Sicherungskopie von dem, was sich derzeit in Ihrem Cache befindet, gemischt mit den fehlerhaften Daten für die Blöcke, die nicht zwischengespeichert sind. Nach dem Booten einer Rettungsdiskette können Sie dasselbe ddin umgekehrter Reihenfolge tun, um die teilweise guten Daten wieder auf die Festplatte zu übertragen und die komplett fehlerhaften Daten zu überschreiben, die sich jetzt dort befinden.

Danach stellen Sie möglicherweise fest, dass automatisierte Wiederherstellungstools ( fsck, testdisk) gut genug funktionieren. Wenn nicht, haben Sie eine Karte, die Sie zur manuellen Wiederherstellung verwenden können. Mithilfe der „Free Block“-Listen von dumpe2fswissen Sie, welche Blöcke Sie ignorieren müssen.

Das meiste, was Sie verloren haben, sind wahrscheinlich Inodes. Es ist eigentlich ziemlich wahrscheinlich, dass Sie keine Datei hattenInhaltin den ersten 4 MB der Festplatte. (Ich habe es mkfs.ext4ohne Optionen auf einer 1 TB großen Bilddatei ausgeführt und der erste Block ohne Metadaten stellte sich als Block 9249 heraus)

Jeder Inode, den Sie wiederherstellen können, identifiziert die Datenblöcke einer ganzen Datei. Und diese Datenblöcke können überall auf der Festplatte verteilt sein, 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, müssen wir uns nur um die Blöcke 0-1023 kümmern. Und die reservierten GDT-Blöcke reichen bis Block 1141! Dies ist die Art von Schaden, die durch einen einfachen e2fsck -b $backup_superblock_number(nach einem Neustart) repariert werden sollte. Sie könnten das zumindest mit versuchen, -num zu sehen, was es denkt.

Answer