破損したファイルシステムを別のハードドライブ上のファイルにイメージングする前に読み取れないデータ量を確認するために、テストの実行ddrescue（構造結果をに送信する）を決定しました。/dev/null
# ddrescue -d -b 4096 -r 3 -f /dev/sda1 /dev/null sda1.log
結局完了するのに3日かかりました。これで現実的なイメージを作成する準備が整いました。しかし、完了するまで3日間待つことはしたくありません。しかし、幸いなことにログddrescueファイルがあるので、不良セクタに触れずに良いセクタだけを強制的に救出することは可能ですか？
いくつかの文書を読んだ後、次のアイデアを思いついた。
# ddrescue -d -b 4096 --fill=+ /dev/sda1 /mnt/sda1.img sda1.log
これはうまくいくでしょうか？良いセクタだけを読み直す別の（好ましい）方法はありますか？
答え1
マニュアルを注意深く読んで、ddrescue次のオプションを見つけてください。
-m file
--domain-logfile=file回復ドメインを完了したとマークされたログファイルのブロックに制限します。文書。これは、リカバリ中にターゲットドライブに障害が発生した場合に便利です。
したがって、呼び出しはddrescue次のようになります。
# ddrescue -d -b 4096 -m sda1.log /dev/sda1 /mnt/sda1.img logfile2.log
答え2
ddecueの機能を理解したので、破損したディスクからデータを回復するときに/ dev / nullに書き込むためにそれを使用しないでください。代わりに、実際の画像ファイルに書き込むために使用して「少なくとも何か」を取得する必要があります。
たとえば、新しいディスクがそのディスクをリポジトリに返すかどうかを知りたい場合は、/ dev / nullに書き込むことをお勧めします。
この場合、「/dev/null 試行」のログファイルを使用するのではなく、空/新しいログファイルを使用してから、実行する操作に応じて複数のパスを試みます。
答え3
2018年のクイック編集：
私はddrescue数年前にハードドライブを救うために時々これを使用しました。
dd表面的に破損したハードドライブよりも高速です。
しかし、dd最初の投稿で事実をそのまま維持することは本当に安全です。
オリジナル投稿
これはとても悪い考え!!
ddrescueを練習して、回復出力を/ dev / nullにスローします。
私が言ったこと破損したファイルシステムを別のハードドライブ上のファイルにイメージングする前に...
ディスクドライブが損傷すると、通常は損傷の程度が増加します。ドライブにアクセスしようとするたびに。
だからこれ破損したドライブを救出する良い方法は次のとおりです。1回のノンストップ操作で最初から最後までディスク全体をイメージしてください！。以降：ディスクドライブを取り外し、静かに保管してください。同様に、破損したドライブに触れるほど、何かを回復する可能性が高くなります。
破損した材料と機械的に接触するたびに、より多くの損傷が発生する可能性があるため、最後の作業のログは次のとおりです。参照ではありませんどのブロックが破損しているかを確認する今。
これは正しいdd構文です生ddを読む不良ブロックも同様です。
dd bs=512 if=/dev/sdX of=/backuprepo/sdXBroken.img conv=noerror,sync
そして、私はそれが辛抱強く働くようにした。