ddrescue
を使用してハードドライブからファイルを回復しています。詳細:
sdb2
、sdb3
)–それぞれに約200GBのデータがあります。Sudo ddrescue -d /dev/sdb2 sdb2.img sdb2.logfile --force -R
。ディスクは私が経験したことからかなり損傷しています:
私は各パーティションでddrescue
を実行していて、何か奇妙なことがわかりましたが、それは私に希望を与えます。
ddrescue
はさまざまな時点でハングしているように見えます。つまり、ipos
とopos
は移動せず、run time
も移動しません。現在のレートは非常に高いままで、変化しません。ここで何が起きてるの?ドライブがしばらくの間完全に応答しなくなっただけですか?ddrescue
は何も救助するための進歩を遂げておらず、last sucessful read
は非常に長い間カウントアップを開始します-本当に無期限に。これが発生したら、^C
を出力し、ドライブの電源を入れ直して、ddrescue
を再開します。驚いたことに、それはすぐに非常に高速でファイルを救出することに成功し始めます。これが続くこともあれば、数秒後に水中で死んでしまうこともあります。次のようになります。
rescued: 10970 MB, errsize: 338 MB, current rate: 15073 kB/s
ipos: 191426 MB, errors: 3806, average rate: 15612 kB/s
opos: 191426 MB, run time: 1.65 m, successful read: 0 s ago
そしてしばらくして:
rescued: 11402 MB, errsize: 600 MB, current rate: 0 B/s
ipos: 144382 MB, errors: 7149, average rate: 4299 kB/s
opos: 144382 MB, run time: 7.66 m, successful read: 2.06 m ago
ドライブが最初に接続されてからしばらくの間、完全に正常に読み取られるという事実は、ここで不良セクタ以外の何かが働いていると私に思わせます。たとえば、電源を入れ直してddrescue
を頻繁に再起動するbashスクリプトを作成できますか?これはドライブを殺しますか?参考までに、私は ddrescue
に関するこの投稿 からいくつかの練習を行いました。
SATA-USBアダプターは異なります。 I/Oエラーが発生したときにディスクを忘れる人もいれば、I/Oエラーを返して続行する人もいます。使用しているアダプタに応じて、さまざまな動作があります。
電源を入れ直すまで、すべてのI/Oをブロックしていると思います。
アダプターをコマンドラインから物理的に切断して再接続し、電源ステータスをリセットすることはおそらくできませんが、 SBデバイスまたはUSBポートをリセットする を試みることはできます。
それでも問題が解決しない場合は、ハードドライブをSATAで直接接続し、ハードドライブをSATAで接続した状態でddrescue
を実行することをお勧めします。そうすれば、各エラーでスタックしているように見えるUSBアダプターをバイパスすることになります。