☰

メインドライブの dd コマンドが間違っています - データを回復するにはどうすればよいですか?

tag-icon • tag-icon linux partitioning data-recovery dd
メインドライブの dd コマンドが間違っています - データを回復するにはどうすればよいですか?

さて、とても迷惑なバカなことが起こりました。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/nvme1n12 つのパーティションが含まれていました:

  • 512 MB EFI ブート パーティション 1 つ
  • 1 TB ドライブの残りの部分をカバーする 1 つの ext4 パーティション

ファイルサイズはarchlinux-2017.08.01-x86_64.iso541065216バイト、または516MB

コンピュータはまだ稼働しており、正常に動作しているようです。出力はlsblk次のようになっています。df -h 前にコマンドを実行すると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ディスクラベル タイプである必要があり、パーティションのサイズ/タイプが間違っています。残念ながら、ISO ファイルのサイズ (516 MB) が原因で、ルート パーティションの最初の 4 MB も上書きされました。

若干異なる出力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 パーティションを再作成するにはどうすればよいでしょうか。最新のカーネルで Arch Linux を実行しています。
  • ルート パーティションの最初の 4 MB に何が含まれていたか (そして破壊されたか) を知る方法はありますか?

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

基本出力（最初の 50 行）dumpe2fs: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

答え1

パーティション テーブルとブート パーティションは簡単に再作成できると想定しているため、ext4 パーティションに焦点を当てます。

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

ext4 ファイルシステムの通常のブロック サイズは 4096 バイトなので、1024 ブロックが失われます。

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

次に、ブロック ビットマップと inode ビットマップがあります。ここから状況が少し悪くなります。これらのいずれかがブロック 1024 より下に存在する場合 (おそらくそうでしょう)、どの inode とブロックが使用されているかに関する情報が失われます。この情報は冗長であり、ディレクトリと inode がすべてそのままであれば、それらを横断して見つかった情報に基づいて fsck によって再構築されます。

しかし、次の問題は inode テーブルです。ここでは、ルート ディレクトリ、ジャーナル、その他の特別な inode など、多くの inode が失われている可能性があります。これらが復元されると便利です。明らかに、ルート ディレクトリは少なくともまだ機能しています。そうでなければ、実行しようとするほぼすべてのコマンドがすでに失敗しているはずです。

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

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

失ったもののほとんどはおそらくinodeです。実際にはファイルが存在しなかった可能性が高いです。コンテンツディスクの最初の 4MB にあります。( mkfs.ext41TB のイメージ ファイルをオプションなしで実行したところ、最初の非メタデータ ブロックはブロック 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。

答え2

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

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

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

答え3

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

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

関連情報