☰

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 〜するログを再生してディスクに記録してみてください。 )

使用dd_rescueまたは救うできるだけ多くのディスクイメージを他のシステムにコピーするには、ディスクを縮小してからイメージコピーを作成します。レプリカの1つですべての復元試行が実行されます。

それでは、拡張データ復旧に関するいくつかのヒントを紹介します。ここ。要するに、

  • パーティションレイアウトがまだ機能しているようです。それ以外の場合は、次のものを使用できます。テストディスクまたは部分パーティション表を復元してみてください。
  • e2fsckファイルシステムをマウント可能な状態に復元することも可能です。ぶら下がっているinodeを配置し、/lost+foundエラーを報告します。
  • ext4magic記録されたメタデータからデータを回復しようとします。ログからファイルを回復できるかどうかは幸運と偶然によって異なりますが、そこには何かがあるかもしれません。
  • 探偵キットほとんどのファイルシステム構造を解析して出力できます。ファイルシステムの内部レイアウトについてある程度知っていて便利な16進エディタがある場合（「スーパーブロックが壊れており、バックアップスーパーブロックは使用されなくなりましたが、十分なデータを選択して直接実行できる」など）ことができます）」のようなもの）、IMOは確かにほとんどのデータを回復するために最も便利なツールです。
  • 写真記録ファイルのように見える一連のバイトを見つけようとします。ファイルの始まり/終わりだけを推測するだけで、ディレクトリ、ファイル名などのファイルシステム構造については何もわからず、断片化されたファイルは見つかりません。

答え2

プロフェッショナルなデータ復旧サービスの一般的な長所と短所をすべて理解し、データ損失によるコストと直接復旧に伴うリスクを比較評価してみたとします。ユーザーはデータが000ドルの価値があるとは思わない。はい数時間の時間を投資する価値があります...

これが私がすることです。

ddで0.5kB / sを継続的に取得している場合は、おそらくこれを試すのに時間を費やす価値はありません。

あなたできるディスクから Testdisk を実行します。それ可能働くコスト/リスクのために他のオプションがない場合...それはあなたの決定です。効果があるかもしれません。

全体的に、これらの問題は政治的地雷原です。ユーザーは、同僚にファイルを再送信するように要求するのが恥ずかしくないか、管理者に直面したくなく、定期的にバックアップしていないため、データ復旧に数千ドルを費やす必要があることを認めます。彼らはあなたが問題を解決し、すべての問題を解決できることを願っています。そしてその過程でドライブが自ら破壊される場合もあります。彼らは自分を救うためにバスの下に投げます。

関連情報