この問題は解決しました初めてddrescue救出する機器について。
1.5TBのハードドライブを入手する必要がありました。
私が使用するコマンドは次のとおりです。
# ddrescue /dev/sdc1 my-part-img my-part-map
ディスクの良好な領域（オプションのパラメータなし）でリカバリを開始すると、読み取り速度（ " current rate"）は約18 MB / sに保たれます。
時々速度が少し遅くなり、元の速度に戻ります。
ただし、ディスクの不良セクタが発生すると速度が大幅に遅くなり、再び18 MB / sに戻りませんが、50 GBの良好なディスクを読み取った後でも約3 MB / sを維持します。問題ありません。
奇妙なことは、現在ディスクの良い領域を3 MB / sでスキャンしているddrescueことです。実際に3MB/sに達したときに停止して再起動し、約2日間を節約しました。ddrescue
最初のパスを完了するために8回を実行する必要がありました。
私の質問は：なぜddrescueあなたは自分の最高速度に戻ろうとしないのですか？簡単な領域を最初にすばやく完了するように文書に明確に規定されたポリシーを考慮するときにこれが行われるべきことであり、私が観察した動作は私にとってバグのように見えます。
-aこの問題を処理するオプションがあるかどうか疑問に思います
--min-read-rate=… 。手動とても簡潔なのでよくわかりません。さらに、このオプションの読み取り速度をどの基準で選択する必要があるのかわかりません。 18MB/s以上でなければなりませんか？
しかし、これを指定するオプションがあるにもかかわらず、これが基本的には行われないという事実に驚きました。
メタアノテーション
質問は主にコメントに基づいていたので、2人のユーザーが質問を終了することに投票しました。
どういう意味なのか知りたいですか？
実際の例では、ソフトウェアの重要な部分の動作をある程度数値的に正確に説明し、文書に記載されている主な設計目標（できるだけ早く完了）を満たしていないことを明らかに示しています。簡単な推論でこれを改善できます。
このソフトウェアはよく知られており、非常に信頼性の高いソースから提供されており、正確なアルゴリズムが装備されており、ほとんどの欠陥がずっと前に削除されたことがわかりました。それで、私はこの予期しない動作の既知の考えられる原因について専門家に尋ねました。しかし、私はこのトピックの専門家ではありません。
また、問題を解決するためにソフトウェアの特定のオプションを使用する必要があるかどうか尋ねましたが、これは非常に正確な質問でした。これに関する文書が見つからなかったため、詳細な側面（このオプションのパラメータを選択する方法）を要求します。
私は仕事についての意見ではないという事実を求めています。意見ではなく実験的な事実で動機づけ
答え1
この問題を処理するために-aまたは--min-read-rate =オプションを使用できるかどうか疑問に思います。しかし、マニュアルがとても簡潔で、わかりません。さらに、このオプションの読み取り速度をどの基準で選択する必要があるのかわかりません。 18MB/s以上でなければなりませんか？
この--min-read-rate=オプションが役に立ちます。最新のドライブは内部エラーチェックに時間を費やす傾向があるため、速度が大幅に遅くなってもエラー状態では報告されません。
50GBの良好なディスクも問題なく読み取ることができます。
これはまた、問題があるかどうかもわからないという意味でもあります。ドライブに問題がある可能性があり、問題を報告しないことにしました。
これで、次のddrescue動的値がサポートされます。--min-read-rate=info ddrescue
If BYTES is 0 (auto), the minimum read rate is recalculated every
second as (average_rate / 10).
しかし、私の経験上、自動設定はあまり役に立たないようです。ドライブが詰まっている場合、特に最初にこのようなことが発生した場合、平均速度はこれが効果的であるほど十分に高くなりません。
だから、最初のパスでは、できるだけ多くのデータを取得したい場合は、まずファーストゾーンで手動でaverage_rate / 10設定し、平均速度はドライブが破損していないときの平均速度です。
たとえば、ここで（約100M / sで実行する必要があるドライブの場合）、選択してから10M後でいつでも戻って、より遅い領域で運を試すことができます。
私が観察した行動はバグのようです。
だからエラーが出たらあなたデバッグする必要があります。同じタイプのドライブエラーがなければ、再現は困難です。ドライブ自体がある種の回復モードに閉じ込められている可能性があります。
欠陥のあるドライブを扱うときは、dmesgバスリセットなどの奇妙なことが起こっていることも確認する必要があります。一部のコントローラは、故障したドライブを処理するために他のコントローラよりも悪いです。
手動介入が避けられない場合もあります。
それにもかかわらず、これは基本的には行われないことに驚きました。
ほとんどのプログラムには適切なデフォルト設定がありません。ddデフォルトはまだ512バイトのブロックサイズを使用することですが、これはほとんどの場合「間違った」選択です。合理的であると見なされることも、時間の経過とともに変化する可能性があります。
私は仕事についての意見ではないという事実を求めています。
良いバックアップを持っている方が彼らに頼るよりも優れていますddrescue。故障したドライブからデータを取得するには、まず運が必要です。データ復旧には多くの個人的な経験と意見が必要です。
私たちが持っているほとんどの修復ツールも愚かです。このツールには中央サーバーに報告する人工知能はありません。だからこの部分の仕事は人間がしなければならない。
答え2
これは少し変な文章ですが、このような状況に直面できる人のために：
-OOPの動作を再現し、各エラーの後に入力ファイルを再開するフラグを使用して、ddrescueに最大読み取り速度を復元させることができました。
残念ながら、エラーが発生した後に〜3MiB / sの速度で回復するように見える理由を詳しく知る機会はありませんでしたが、私の経験を共有したいと思いました。