☰

物理エラーのある ext3 ファイルシステムからファイルを回収する

tag-icon • tag-icon linux data-recovery ext2
物理エラーのある ext3 ファイルシステムからファイルを回収する

クラッシュした Linux ラップトップのディスクがあり、そのディスクには、不幸な所有者が可能な限り取り戻したいファイルが含まれています (バックアップ ソリューションは不要です)。私はこれまでこのディスクに何の関わりもありませんでした。このディスクは OS X と Ubuntu 11.10 の両方で認識されます。

root@ubuntu1110:~# fdisk -l /dev/sdc

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 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
Disk identifier: 0x80d549b4

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *          63   953602334   476801136   83  Linux
/dev/sdc2       953602335   976768064    11582865    5  Extended
/dev/sdc5       953602398   976768064    11582833+  82  Linux swap / Solaris

これは、スワップ パーティションを持つ Linux ディストリビューションの標準インストールと一致しているように見えます。

残念ながら、Ubuntu が sdc1 パーティションをマウントできないと表示した後、dmesg にかなり厄介なメッセージが表示されます。

[  181.228092] sd 6:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[  181.232176] sd 6:0:0:0: [sdc] Write Protect is off
[  181.232181] sd 6:0:0:0: [sdc] Mode Sense: 21 00 00 00
[  181.236359] sd 6:0:0:0: [sdc] No Caching mode page present
[  181.236364] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  181.246696] sd 6:0:0:0: [sdc] No Caching mode page present
[  181.246707] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  182.835915]  sdc: sdc1 sdc2 < sdc5 >
[  182.854199] sd 6:0:0:0: [sdc] No Caching mode page present
[  182.854204] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[  182.854208] sd 6:0:0:0: [sdc] Attached SCSI disk
[  218.250174] sd 6:0:0:0: [sdc] Unhandled sense code
[  218.250179] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  218.250182] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  218.250187] Info fld=0x0
[  218.250188] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  218.250193] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 01 08 00 00 08 00
[  218.250200] end_request: I/O error, dev sdc, sector 264
[  218.250206] Buffer I/O error on device sdc, logical block 33
[  255.398994] sd 6:0:0:0: [sdc] Unhandled sense code
[  255.399029] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  255.399032] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  255.399037] Info fld=0x0
[  255.399038] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  255.399053] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 01 08 00 00 08 00
[  255.399061] end_request: I/O error, dev sdc, sector 264
[  255.399066] Buffer I/O error on device sdc, logical block 33
[  281.340599] sd 6:0:0:0: [sdc] Unhandled sense code
[  281.340609] sd 6:0:0:0: [sdc]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[  281.340618] sd 6:0:0:0: [sdc]  Sense Key : Hardware Error [current] 
[  281.340653] Info fld=0x0
[  281.340655] sd 6:0:0:0: [sdc]  Add. Sense: No additional sense information
[  281.340659] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 00 67 00 00 08 00
[  281.340667] end_request: I/O error, dev sdc, sector 103
[  281.340739] EXT3-fs (sdc1): error: can't read group descriptor 4

私の現在の理論は、ハードディスクの予備ブロックが不足しているため、実際に不良ブロックが発生し、それがパーティションをマウントするときに使用される領域にあるというものです。これは dd によって確認されています。

root@ubuntu1110:~# dd if=/dev/sdc1 of=/dev/null bs=10240 conv=noerror
dd: reading `/dev/sdc1': Input/output error
2+0 records in
2+0 records out
20480 bytes (20 kB) copied, 44.7084 s, 0.5 kB/s
dd: reading `/dev/sdc1': Input/output error
9+1 records in
9+1 records out
96256 bytes (96 kB) copied, 162.933 s, 0.6 kB/s
dd: reading `/dev/sdc1': Input/output error
9+1 records in
9+1 records out
96256 bytes (96 kB) copied, 180.083 s, 0.5 kB/s

プロセスの早い段階で不良ブロックが発生し、プロセスの後半でも転送速度が非常に遅くなります (図示せず)

今の私の問題は、ここからどのようにアプローチするかです。壊れた ext2/ext3 ファイルシステムから読み取り、ディスクに残っているファイルをコピーできるものが必要ですが、過去 15 年間 Linux システム管理をあまり行っていないため、検索するための適切な用語がわかりません。

おそらく、夜間にディスク イメージをコピーすることはできますが、その場合、「このブロックは不良です」という情報は失われます。

このような状況ではどのようなプログラムが役立つでしょうか?

答え1

ディスク回復の第一ルール:ディスクの使用を中止してください。 ハードウェアに問題がある場合（ヘッドクラッシュなど）、使用するとさらに損傷するリスクがあります。ファイルシステムが破損している場合は、使用したり、使用したりするmountと、さらにfsck悪化する可能性があります。（roモードでも！mount -t ext3 -o ro 意思ジャーナルを再生してディスクに書き込むことを試みます。)

使用レスキューまたはddrescueディスク イメージを可能な限り他のシステムにコピーし、ディスクを片付けて、イメージのコピーを作成します。 コピーの 1 つからすべての回復処理を実行します。

さて、私はextデータ復旧のためのヒントをいくつか紹介しましたここ。 要するに、

  • パーティションレイアウトはまだ有効のようです。そうでない場合は、テストディスクまたはgパートパーティション テーブルの回復を試みます。
  • e2fsckファイルシステムをマウント可能な状態に戻すことができる可能性があります。 ぶら下がっている inode を配置し/lost+found、エラーを報告します。
  • ext4マジックジャーナルされたメタデータからデータを回復しようとします。ジャーナルからファイルを回復できるかどうかは運と偶然次第ですが、そこに何かが入っている可能性はあります。
  • 探偵キットほとんどのファイルシステム構造を解析して出力できます。ファイルシステムの内部レイアウトについて十分な知識があり、16 進エディタが手元にある場合 (「スーパーブロックが破損しており、バックアップ スーパーブロックが古くなっていますが、自分で再構築するのに十分なデータを取り出すことができます」などの操作を行うため)、これはほとんどのデータを回復するための最も便利なツールだと私は思います。
  • フォトレックファイルのように見えるバイトシーケンスを検索します。ファイルの先頭と末尾を推測するだけで、ディレクトリやファイル名などのファイルシステム構造については何も知らず、断片化されたファイルは検索しません。

答え2

プロのデータ復旧サービスの通常の長所と短所をすべて検討し、失われたデータのコストと自分で行うリスクを比較検討したと仮定します...ユーザーは、データが数千ドルの価値がないと判断しましたが、は何時間も時間を費やす価値があります...

私ならこうします。

dd で一貫して 0.5kB/s が得られた場合は、おそらくこれを試してみる価値はありません。

あなたできたディスクに対してTestdiskを実行します。かもしれないうまくいく。コストやリスクを考慮して他に選択肢がない場合は、それはあなたの判断次第です。うまくいくかもしれません。

一般的に、真面目な話、これらの問題は政治的な地雷原です。ユーザーは、同僚にファイルを再送信するよう頼むのが恥ずかしいか、経営陣と顔を合わせて定期的なバックアップを実行していなかったことを認めたくないため、データ復旧に何千ドルも費やす必要があります。彼らは、あなたが問題を解決してすべての問題を解決してくれることを期待しています...そして、その過程でドライブが自己破壊した場合、彼らは自分の身を守るためにあなたを犠牲にするでしょう。

関連情報