メインドライブの間違ったddコマンド-データを回復する方法は？

Question

さて、迷惑な愚かなことが起こりました。 Arch Linux ISOファイルをUSBサムドライブにコピーしたかったのですが、急いでいて、誤ってメインドライブをofパラメーターとして入力しました。

詳細は次のとおりです。

$ Sudo dd bs=4MB if=archlinux-2017.08.01-x86_64.iso of=/dev/nvme1n1

/dev/nvme1n1は/dev/sdbである必要があります。

私のメインドライブ/dev/nvme1n1には2つのパーティションが含まれていました：

1つの512MBEFIブートパーティション
1台の残りの部分にまたがる1つのext4パーティションTBドライブ

archlinux-2017.08.01-x86_64.isoのファイルサイズは541065216バイト、つまり516 MB

コンピューターはまだ実行中であり、正常に動作しているように見えます。lsblkおよびdf -h before ddコマンドを実行する出力があります。出力はまったく同じコマンドを実行したときと同じです。データがキャッシュされているためだと思います。

$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme1n1 259:5 0 931.5G 0 disk ├─nvme1n1p1 259:6 0 512M 0 part /boot └─nvme1n1p2 259:7 0 931G 0 part / $ df -h Filesystem Size Used Avail Use% Mounted on /dev/nvme1n1p2 916G 22G 848G 3% / /dev/nvme1n1p1 511M 36M 476M 7% /boot

ls /bootは引き続きディレクトリコンテンツ（おそらくキャッシュされた情報）を出力しますが、ファイルコンテンツが破損しており、ls /boot/EFIまたはls /boot/loaderを実行すると、多くのInput/output errorを含むランダムな文字で画面がいっぱいになります。

ここにいくつかのより多くの情報があります：

$ cat /proc/partitions major minor #blocks name 259 5 976762584 nvme1n1 259 6 524288 nvme1n1p1 259 7 976237255 nvme1n1p2 $ Sudo fdisk -l /dev/nvme1n1 Disk /dev/nvme1n1: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x282bad86 Device Boot Start End Sectors Size Id Type /dev/nvme1n1p1 * 0 1056767 1056768 516M 0 Empty /dev/nvme1n1p2 164 131235 131072 64M ef EFI (FAT-12/16/32)

fdiskの出力を見ると、パーティションテーブル（およびおそらくブートパーティション上のすべてのデータ）が破壊されていることがかなり明らかです。 gpt disklabelタイプである必要があり、パーティションのサイズ/タイプが間違っています。残念ながら、ISOファイルサイズ（516 MB）のため、ルートパーティションの最初の4MBも上書きされました。

gdiskとは少し異なる出力：

$ Sudo gdisk /dev/nvme1n1 # selected GPT when asked "Found valid MBR and GPT. Which do you want to use?" Command (? for help): p Disk /dev/nvme1n1: 1953525168 sectors, 931.5 GiB Model: Samsung SSD 960 EVO 1TB Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): <guid> Partition table holds up to 248 entries Main partition table begins at sector 2 and ends at sector 63 First usable sector is 64, last usable sector is 1056704 Partitions will be aligned on 8-sector boundaries Total free space is 1 sectors (512 bytes) Number Start (sector) End (sector) Size Code Name 2 164 131235 64.0 MiB 0700 ISOHybrid1

私が見つけたいくつかの関連する質問：

すでにtestdiskユーティリティをインストールしましたが、これは有望に見えますが、正しい手順を実行していることを確認したいと思いますコンピュータの実行中に。今すぐシャットダウンすると、起動しなくなるので、次の質問があります。

この状況から回復するための最良の方法は何ですか？
パーティションテーブルを前の形式に復元するにはどうすればよいですか？また、/ bootパーティションを再作成するにはどうすればよいですか？私は最新のカーネルでArchLinuxを実行しています。
ルートパーティションの最初の4MBに何が含まれていたか（そして破壊されたか）を知る方法はありますか？

編集：dumpe2fsコマンドを実行する@ WumpusQ.Wumbleyの提案に基づいて、ここに詳細情報を追加します。

dumpe2fsの基本出力（最初の50行）： https://Pastebin.com/fBuFRQfE

私にはそれはかなり正常に見えますが、ファイルシステムのマジックナンバー（0xEF53）でさえ正しいです。

これにGroup 0が続きます：

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

その後、[...]8192 free inodes, 0 directories, 8192 unused inodes [...]と言うグループがたくさん続きます。実際にいくつかのディレクトリを報告する最初のグループは、Group 3648まで、または約25,000行後です。

Group 3648: (Blocks 119537664-119570431) csum 0xa9ea [ITABLE_ZEROED] Block bitmap at 119537664 (+0) Inode bitmap at 119537680 (+16) Inode table at 119537696-119538207 (+32) 23930 free blocks, 1670 free inodes, 614 directories, 1670 unused inodes Free blocks: 119546502-119570431 Free inodes: 29890939-29892608

ファイルシステム全体に多くのバックアップスーパーブロックがあります。

$ Sudo dumpe2fs /dev/nvme1n1p2 | grep -i superblock | wc -l dumpe2fs 1.43.5 (04-Aug-2017) 19

user240960 · Accepted Answer

パーティションテーブルとブートパーティションは簡単に再作成できると思いますので、ext4パーティションに注目します。

ファイルシステムのレイアウトは、ファイルシステムの作成時に使用されるオプションに多少依存します。一般的なケースについて説明します。デバイスでdumpe2fsを実行すると、これが自分のものと一致するかどうかを確認できます（ディスクから読み取るのではなく、キャッシュ内のすべてのトップレベルメタデータが見つかることを願っています）。

Ext4ファイルシステムの通常のブロックサイズは4096バイトであるため、1024ブロックが失われています。

最初に上書きされたのは、プライマリスーパーブロックであるブロック0でした。バックアップスーパーブロックがあるため、これ自体は問題ではありません。その後にグループ記述子テーブルがあり、ファイルシステム内にもバックアップがあります。

次に、ブロックビットマップとiノードビットマップがあります。これはニュースが少し悪化し始めるところです。これらのいずれかがブロック1024を下回っている場合（おそらくそうです）、どのiノードとブロックが使用されているかに関する情報が失われています。この情報は冗長であり、すべてのディレクトリとiノードをトラバースしていることがわかったものに基づいてfsckによって再構築されます（それらが無傷の場合）。

しかし、次はiノードテーブルです。ここでは、ルートディレクトリ、ジャーナル、その他の特別なiノードを含む多くのiノードが失われている可能性があります。それらを取り戻すのは素晴らしいことです。明らかに、少なくともルートディレクトリはまだ機能しているか、実行しようとしているほぼすべてのコマンドがすでに失敗しているでしょう。

ここでdd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024を実行すると、現在キャッシュにあるものすべてのバックアップコピーが取得され、キャッシュされていないブロックの不良データと混合されます。次に、レスキューディスクを起動した後、同じddを逆に実行して、部分的に良好なデータをディスクに戻し、現在存在するすべての不良なデータを上書きできます。

この後、自動回復ツール（fsck、testdisk）が十分に機能することがわかります。そうでない場合は、手動リカバリに役立つマップがあります。 dumpe2fsの「空きブロック」リストを使用すると、無視するブロックがわかります。

失ったもののほとんどはおそらくiノードです。実際には、ディスクの最初の4MBにファイルがない可能性がかなりありますcontents。（1TBの画像ファイルでオプションなしでmkfs.ext4を実行したところ、最初の非metdataブロックがブロック9249であることが判明しました）

管理するすべてのiノードは、ファイル全体のデータブロックを識別します。また、これらのデータブロックは、必ずしも近くではなく、ディスク全体に配置されている可能性があります。

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でそれを試して、それが何を考えているかを確認することができます。

Rod Smith · Answer

ディスクがGPTを使用している場合、パーティションテーブルは、ディスクの最後にあるバックアップGPTデータを使用して回復可能である必要があります。これはgdiskで行うことができます。詳細については、データ復旧に関するgdiskドキュメントを参照してください。簡単に言うと、ディスクでgdiskを起動すると、おそらく損傷に気づき、バックアップGPTデータとMBRデータのどちらを使用するかを尋ねられます。。 GPTオプションを選択してから変更を書き込むと、パーティションテーブルが修正されます。 gdiskがどのパーティションテーブルを使用するかを尋ねない場合でも、リカバリと変換メニューのcオプションを使用してバックアップテーブルをロードできる可能性があります。

これが失敗した場合でも、/sys/block/nvme1n1/nvme1n1p1/startファイルと/sys/block/nvme1n1/nvme1n1p1/sizeファイル（および同様に/dev/nvme1n1p2）のデータを使用して、パーティションテーブル（または少なくともパーティションの開始点と終了点）を再作成できます。ただし、このデータに頼る場合は、[〜＃〜] not [〜＃〜]とは逆に、コンピュータをシャットダウンする必要があります。 hek2mglがアドバイスしたこと。とはいえ、hek2mglは、ディスクを現在の状態で使用し続けると、事態が悪化するリスクがあることは間違いではありません。全体として、最善の妥協案は、パーティションテーブルの問題をできるだけ早く修正してから、シャットダウンして緊急ディスクからファイルシステムの問題を修正することです。

残念ながら、あなたのESPは乾杯です。ディスクレイアウトを考えると、ESPを/bootにマウントし、カーネルをそこに保存したと思います。したがって、あなたはchrootまたはその他の手段を使用してカーネルパッケージを再インストールする必要があります。ブートローダーまたはブートマネージャーについても同様です。

hek2mgl · Answer

コンピューターをシャットダウンします（すぐに）
レスキューシステムで起動します。
testdiskを実行して、データの回復を試みます。（十分なスペースがある場合は、ddを使用してデバイスから画像を取得し、その画像に対してtestdiskを実行します）

なぜすぐにコンピュータをシャットダウンする必要があるのですか？新しいファイルが作成される場合（/ run probalyにあるもの）または追加される場合（/ var/log/...）、ファイルシステムは既存の（悪い！）情報を調べてデータの保存場所を決定する必要があります。この決定が悪い情報に基づいて行われる場合、既存のデータブロックが上書きされるリスクが高くなります。それは彼らを永遠に失ってしまいます。 testdiskやphotorecのようなツールでも。