パーティション テーブルとブート パーティションは簡単に再作成できると思いますので、ext4 パーティションに注目します。
ファイルシステムのレイアウトは、作成時に使用するオプションに多少依存します。一般的なケースについて説明します。 dumpe2fs を実行すると、これがあなたのものと一致するかどうかを確認できます デバイス上で (これにより、ディスクから読み取るのではなく、キャッシュ内のすべての最上位メタデータが見つかることが期待されます)。
ext4 ファイルシステムの通常のブロック サイズは 4096 バイトであるため、1024 ブロックが失われます。
最初に上書きされたのは、プライマリ スーパーブロックであるブロック 0 でした。バックアップ スーパーブロックがあるため、これ自体は問題ではありません。その後はグループ記述子テーブルで、ファイルシステム内にもバックアップがあります。
次に、ブロック ビットマップと inode ビットマップがあります。これは、ニュースが少し悪化し始めるところです。これらのいずれかがブロック 1024 より下にある場合 (おそらくそうです)、使用中の inode とブロックに関する情報が失われています。この情報は冗長であり、すべてのディレクトリと inode を走査して見つかったものに基づいて fsck によって再構築されます (それらが損なわれていない場合)。
しかし、次は i ノード テーブルです。ここでは、ルート ディレクトリ、ジャーナル、およびその他の特別な i ノードを含む多くの i ノードが失われている可能性があります。それらが戻ってくるといいですね。明らかに、少なくともルート ディレクトリはまだ機能しているか、実行しようとしているほぼすべてのコマンドがすでに失敗しています。
dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024 を実行すると これで、現在キャッシュにあるもののバックアップ コピーが取得され、キャッシュされていないブロックの不良データが混在します。次に、レスキュー ディスクを起動した後、同じ dd を実行できます。 逆に、部分的に正常なデータをディスクに戻し、現在そこにあるすべての不良データを上書きします。
この後、自動回復ツール (fsck) が見つかるかもしれません。 、 testdisk ) 十分に機能します。そうでない場合は、手動での回復に役立つマップがあります。 dumpe2fs の「空きブロック」リストを使用する 、無視するブロックを知っています。
失ったもののほとんどは、おそらく inode です。実際には、ファイル contents がなかった可能性がかなり高いです ディスクの最初の 4MB に。 (私は mkfs.ext4 を実行しました 1 TB のイメージ ファイルにオプションを指定せず、メタデータ以外の最初のブロックがブロック 9249 であることが判明した)
回復するすべての inode は、ファイル全体のデータ ブロックを識別します。また、これらのデータ ブロックは、必ずしも近くにあるとは限らず、ディスク全体に配置される場合があります。
2 日目
Pastebin に投稿されたダンプは素晴らしいニュースを明らかにしています:
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
ファイルシステムの先頭の 4MB だけが上書きされたと考えられるため、ブロック 0 ～ 1023 についてのみ心配する必要があります。そして、予約された GDT ブロックは、ブロック 1141 までずっと続きます!これは、単純な e2fsck -b $backup_superblock_number で修復する必要がある種類の損傷です (再起動後)。少なくとも -n でそれを試すことができます