DDRescueには数か月かかりますがエラーはありませんか？
同じエラーで他の人を見つけるのに苦労しており、今後の最善の道を見つけようとしています。
異常に遅いハードドライブがあり、起動が停止しました。 clonezillaクローンが失敗し、clonezillaライブCDに含まれているgnuレスキューツールを使用して、ddrescueを開始しました。 2 TB=ドライブの場合、平均で約400 kBpsと信じられないほど遅くなります。そのため、この時点でほぼ4か月と推定しています！最後のバックアップは約2年前の悲しいことに、私はそれから降りたい多くの写真です。驚いたことに、3日間かかったとしても、これまでのところエラーがなく、約50 GBが救われたということです。今後の最適なパスについていくつか質問があります。なぜそんなに時間がかかるがエラーもないのか。
ドライブは正常に読み取るのに永遠にかかっていますが、実際には失敗せず、コピー時間が遅くなっていますか？ハードドライブ自体は問題ありませんが、コントロールボードのようなものが問題ですか？
ログファイルがどこに行く可能性が高いか私は非常に心配しています。コンピューターが安定していて、コマンドが4か月間エラーを起こさないようにすることはできません。それを数週間も実行し続けることについて話しているなら、そのログファイルをフラッシュドライブに入れたいです。元々は新しい大きなハードドライブに入ると思っていましたが、RAMドライブで発生する可能性が高いことに気づきましたclonezilla_liveが利用しています。フォーマットされたUSBドライブを挿入してマウントしても安全ですか？ログファイルをコピーしてからddrescueを再起動しますか？clonezillaシェルは、ブート時に存在しなかったUSBスティックを挿入したことを認識しますので、マウントできますか？
Sudo fdisk -lディスクを一覧表示してからディレクトリを作成しますか？ Sudo mkdir /logfile/usb次にマウントしますか？ Sudo mount /dev/sdb1 /media/usb、次にコピーしますか？
任意のフィードバックをいただければ幸いです。私はUnixシェルを少しねじ込んで、ZプールRAIDをセットアップしましたが、常に、自分が何をしているかを正確に知っているときは、Linuxではなく、最低限のバージョンは言うまでもありません。
誰かが興味を持っているか、数年でこれのアーカイブされたバージョンに遭遇した場合。私は2か月待って、コピーを再開するためのログファイルを作成しました。 （コンピューターが再起動されるまで）読み取りエラーが2度発生し始め、一度電源が切れました。何カ月もコピーした後、USBアダプターを介して別のラップトップにバックアップを接続しました。コピーされなかった7.5 MBの〜2 TBがおそらく残っていました（-r3（3回の再試行）後にエラーが発生しました）。判読できませんでしたが、次の指示に従ってパーティションテーブルを再構築しました： https://perrohunter.com/repair-a-mac-os-x-hfs-partition-table/ -私はしなければなりませんでしたこのドライブは古いドライブよりもはるかに大きいため、ブロックサイズを変更します。
その後、問題なく動作しました。ディスクの検証と修復、およびディスクユーティリティでの権限の修復を行いましたが、問題なく起動しました。
本当の教訓は？私は非常に重要なファイル（写真とドキュメント）とオンサイトでミラー化された起動可能なバックアップにbackblazeを使用しています。
ddrescueは、第2フェーズに達するまで不良セクターをマークします。 https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html
（第2段階;トリミング）トリミングは1つのパスで行われます。トリミングされていないブロックごとに、読み取りは、ブロックのリーディングエッジから不良セクターが見つかるまで、一度に1セクターずつ転送します。次に、ブロックの最後のエッジから不良セクターが見つかるまで、一度に1セクターずつ逆方向に読み取ります。次に、見つかった不良セクター（存在する場合）を不良セクターとしてマークし、それを読み取ろうとせずに、残りのブロックを非スクレイピングとしてマークします。
そして問題は、このフェーズが始まるまでにはかなりの時間がかかることです。 3つのパスに分割されます。
- タイムアウトなどに応じて、ブロックを
rescued、non-trimmed、non-triedとして前方にコピーしてマークします。 - 逆方向にコピーしてすべての
non-triedブロックを読み取る - スキップすることなく前方にコピーして、トリミングの大きなエラーに備える
残念ながら、エラーの量（時間、日、週、場合によっては月）に依存するため、このフェーズにかかる時間を予測することはできません。
注：--retry-passes=n（r）フラグは、4番目のフェーズでのみ重要です。
（第4段階;再試行）オプションで、指定された再試行回数に達するまで不良セクターの読み取りを再試行します。
そのため、再試行を減らすことで、パスを使用して最初のフェーズを高速化しません。
ただし、一部のブロックが「救済済み」としてマークされている場合は、ddrescueログファイルで確認できるため、ドライブの一部またはすべてのデータが救出されることを期待できます。次に例を示します。
# pos size status
0x00000000 0x00117000 +
0x00117000 0x00000200 -
0x00117200 0x00001000 /
0x00118200 0x00007E00 *
0x00120000 0x00048000 ?
ログファイルに+- statusの行が含まれている場合は、希望があります。 「救出された」という意味です。ただし、?（試していない）と*（試していない）のみが含まれている場合は、あきらめることができると思います。もちろん最初はドライブに欠陥があるだけの可能性もありますが、これは小さなチャンスだと思います。しかし、2台目のPCでddrescueを実行する余裕がある場合は、データの重要度に応じて試してみてください。最終的な希望は、ヘッド/エレクトロニクスを交換することですが、これは高価になる可能性があります。
ログを分析する別の方法は、ddrescueログビューアを使用することです https://sourceforge.net/projects/ddrescueview/
Ddrescue GUIとddrescueログビューアが含まれているため、私は Parted Magic を使用しています。
ここでは、フェーズ1、パス2（逆方向にコピー）の途中にあるビューアのスクリーンショットを見ることができます。 
矢印は現在の位置を示します。ご覧のとおり、このドライブの中央には多くの考えられる不良セクター（この段階では「トリミングされていない」とマークされています）があり、それが私が諦めた理由です。
データがまだコピーされていることを確認してください-出力ファイルを確認し、そのサイズが増加し続けることを確認してください。故障したハードドライブは、一度に大量のデータをコピーしようとするとフリーズする傾向があります。
何も実行されていないように見える場合は、おそらく操作を停止し、戻って一度に1つのディレクトリをコピーすることをお勧めします。これにより、これが再び発生した場合でも、少なくとも完全なディレクトリが作成されます。正常に機能している場合は、1〜2日そのままにしておくことができます。時間の見積もりはしばしばひどく不正確ですが、それは間違いなく1ヶ月かかるべきではありません！
私はddrescueに慣れていませんが、仕事でData Rescueをよく使用します。1日以内に完了しないと、完全なハードドライブイメージが完成したことはありません。そうは言っても、アプリケーションを再インストールして設定を再構成することはできますが、ドキュメントと画像を置き換えることはできないため、必要なディレクトリ（おそらく/ home）のみをコピーするのが最善です。
ログファイルに関する限り、データレスキューユーティリティの実行中はログファイルに触れません。