USB 3ドライブエンクロージャを介して接続された障害のある750 GBハードドライブから可能な限り多くのデータを回復しようとしています。
ドライブ自体にはbadblocks、Linux で検出された1500個を超える不良ブロックがあります。
コンピューターに完全にマウントされます(macOS 10.12を実行)が、破損したブロックのデータが読み取られると、ドライブは数秒間アイドル状態になり、から消えてから/dev再び表示されます。再び戻って。
最初の不良ブロックは、ディスクの先頭から約136 GiBで発生しますが、これだけではありません。これはbadblocks、からの出力と、両方ddとがddrescue失敗した場合に証明されます。
ddそしてddrescue、両方のドライブが、その後から消えるので、彼らは、不良ブロックからデータを読み込むとすぐに失敗します/dev:
dd if=/dev/rdisk3 of=image.img bs=16m:
ddrescue -v /dev/disk4 image.img logfile:
ddrescue同じログファイルで最初の終了後に再実行すると、すぐに終了し、それ以上進むことはありません。
私はファイルシステムを横断していくつかのファイルに正常にアクセスできるので、アクセス可能なファイルとアクセスできないファイルを判別するスクリプトを作成したので、ディスクから既知の正常なファイルをコピーできます。ただし、これは低速であり、ディスクをさらに損傷する可能性があることを心配しています。
いずれにも同様のツールがあるddか、ddrescue単にドライブが不良ブロックを読めば終了自動的に再マウントの代わりにするのを待ち、このドライブからデータを回復することができ、?
macOSとLinux(Ubuntu)の両方を使用できるので、どちらのプラットフォームのソリューションでも機能します。
/devとは、消えるという意味です(再マウント時に新しい識別子が割り当てられることもあります)。ddrescue再度実行すると、すぐに終了し、それ以上進むことはありません。ログファイルを操作して、結果が得られるかどうかを確認します。
badblocks、問題はありませんでした?ddrescue --directオプションを試しましたか?


/devは、umountコマンドではなく「から消える」という意味ですか?用語の混乱を避けたいと思っています。ddrescue同じログファイルで起動すると、中断された実行を継続することになっていると思います。たぶん、何度も何度も実行する簡単なスクリプトを書くことができddrescueます。別のアプローチは、最初のログファイルを作成し(badblocks結果に基づいて)、ddrescue問題のあるセクターに触れないようにすることです。あるddrescuelog役立つかもしれないツールが。ただのアイデア、私は自分でやったことがない。