背景/背景:
現在USBからデータを回復するためにGNU ddrescue 1.18.1を実行していますが、disk2s1パーティションに仮想ディスクイメージを書き込んでいる間にUSBケーブルが切断されました。最初は2番目のパーティション（disk2s2）を復元し、3番目のステップ（分割）に達したことを確認しました。ネットワークストレージに画像を配置しています。
質問：
私はこのステップが定期的であることを知りました。現在の状態情報（2つのエラーのみが表示されます）を考慮して、通過できるループ数を計算する方法はありますか？
状態：
更新/編集：
だから私はまだddrescueツールを使って完了したサイクル/時間を推定する方法に興味があります。コメントに基づいて、現在実行中のdisk2s1パーティションのログファイルの評価を追加します（disk2s2は14.5時間後に完了し、約6時間で1人のユーザーが中断されました）。
完了したパーティションログ
完了したばかりのパーティションのログを確認した結果です。
参照（ddrescueアルゴリズムの注意）：
4つのアルゴリズム
GNU ddrescueはddの派生物ではなく、ddとも関係ありません。両方とも、あるデバイスから別のデバイスにデータをコピーするために使用できます。主な違いは、ddrescueが複雑なアルゴリズムを使用して故障したドライブからデータをコピーして、追加の損傷を最小限に抑えることです。
Ddrescueは、進行中の回復状態を効率的に管理し、最初に良好な部品を回復しようとした後、後で不良（または遅い）領域で読み取りをスケジュールします。これにより、故障したドライブから最終的に回復できるデータ量が最大になります。
標準のddユーティリティを使用すると、故障したドライブのデータを保存できますが、データを順次読み取ってドライブの先頭にエラーがある場合は、何も保存せずにドライブを使い果たすことができます。
他のプログラムはデータを順次読み出しますが、エラーが見つかった場合は小さな読み出しに切り替えます。これは、間違った領域でより多くの時間を費やし、表面、ヘッド、ドライブメカニズムをできるだけ早く取り除くのではなく、損傷するため、悪い考えです。この動作は、残りの良好なデータを回復する可能性を減らします。
ddrescueのアルゴリズムは次のとおりです（ユーザーはいつでもプロセスを中断できますが、不良ドライブはカーネルが放棄されるまで長い間ddrescueをブロックできることに注意してください）。
1）（オプション）マルチパートまたは以前に中断された構造の状態を説明するログファイルを読みます。ログファイルが指定されていない、空である、または存在しない場合、すべての回復ドメインは試行されていないとマークされます。
2）（ステップ1;コピー）入力ファイルの未試行部分を読み取り、失敗したブロックをトリミングしていないとマークしてスキップします。また、遅い領域をスキップします。スキップされた領域は後で2回の追加パス（前に）で試行され、すべての構造領域が試行されるまで各パスの後に方向を変更します。 3番目のパスはスイープで、ジャンプを無効にします。 （目的は、大きなエラーの範囲をすばやく把握し、ログファイルを小さく保ち、クリーンアップのための良い開始点を提供することです。）大きなチャンクの試みられていない領域のみを読み取ります。トリミング、分割、再試行はセクタごとに行われます。各セクタに対して最大2回の試行が行われます。このステップの最初の試み（通常はブロック読み取りの一部として、時には単一のセクター読み取りへ）と、次のステップの2番目は単一のセクター読み取りで行われます。
3）（2番目のステップ、トリミング）不良セクタが見つかるまでトリミングされていない最小ブロックの前端から始まり、一度に1セクタずつ前に読みます。次に、不良セクタが見つかるまで、同じブロックの後端から1セクタ後ろに読み込みます。トリムされていないブロックごとに見つかった不良セクタを不良セクタとしてマークし、残りのブロックを読み取ろうとせずに分割されていないとマークします。トリムされていないブロックがなくなるまでこの操作を繰り返します。 （未処理の大きなブロックは小さなブロックに関連付けられているため、そのエッジには良いデータの割合が少なくなります。）
4）（ステップ3;分割）不良セクタが見つかるまで、最大の非分割ブロックの中心から始まり、一度に1セクタずつ前に読みます。その後、見つかった不良セクタが最初に試行されなかった場合は、不良セクタが見つかるまで同じブロックの中心から1セクタ後に読みます。ログファイルが「--logfile-size」より大きい場合は、ログファイルのエントリ数が「--logfile-size」を下回るまで最大の非分割ブロックを順次読み込みます。分割されていない残りのすべてのブロックが7つ未満のセクタを持つまでこの操作を繰り返します。次に、分割されていない残りのブロックを順番に読み出す。
5）（ステップ4、再試行）指定された再試行回数に達するまで、オプションで不良セクタの読み取りを再試行できます。各不良セクタはパスごとに一度だけ試行されます。 Ddrescueは、不良セクタを回復できないのか、再試行後に最終的に読み取られるのかを知りません。
6) オプションで、後で使用するためにログファイルに記録します。
合計エラーサイズ（ 'errsize'）は、トリミングされていない、分割されていない、不良セクタブロックのすべてのサイズの合計です。コピーフェーズ中に増加し、クリーンアップ、分割、および再試行中に減少する可能性があります。 ddrescue が失敗したチャンクを分割して小さくすることで、エラーの数が増えますが、エラーの合計サイズは小さくなります。
ログファイルは定期的に、ddrescueが完了または中断されるとディスクに保存されます。したがって、競合が発生した場合は、最小限の回復のみで回復できます。保存間隔は、ログファイルのサイズによって30秒から5分まで異なります。ログファイルが大きいほど、長い間隔で保存されます。
また、入力ファイルの異なる領域をコピーする複数のコマンドだけでなく、異なるサブセットに対して複数のリカバリを試みる場合でも、同じログファイルを使用できます。この例を見てください。
ディスクの最も重要な部分を最初に保存します。 ddrescue -i0 -s50MiB /dev/hdc hdimage ログファイル ddrescue -i0 -s1MiB -d -r3 /dev/hdc hdimage ログファイル
次に、いくつかの重要なディスク領域を保存します。 ddrescue -i30GiB -s10GiB /dev/hdc hdimage ログファイル ddrescue -i230GiB -s5GiB /dev/hdc hdimage ログファイル
残りを保存します（すでに完了したジョブを再複製せずに）。 ddrescue /dev/hdc hdimage ログファイル ddrescue -d -r3 /dev/hdc hdimage ログファイル
答え1
この質問は10ヶ月前に要求されましたが、いくつかの要因によって回復サイクルがまだ実行されている可能性があるため、回答は関連性がある可能性があります。慈悲深い意図はありません。
その理由は、時間の推定はほとんど不可能ですが、時には次のようなおおよそのアイデアを得ることができるからです。最も明白な理由の1つは、ドライブが不良セクタを読み取るのにどれくらい時間がかかるかを予測できず、ddrescueが各セクタを読み込んで再試行すると予想する場合は時間がかかる可能性があることです。たとえば、私は現在、小さな500GBドライブの回復を2週間以上進めています。しかし、私の状況は、ドライブが暗号化されていて何でも正常に読み取るには、パーティションテーブル、ブートセクタ、およびディスクのその他の重要な部分を持つすべてのセクタをインポートする必要があるため、状況がより複雑です。 ddrescueに加えて、すべての不良セクタが現れる可能性を高めるために他の技術も使用されます。 IOW、あなたのユニークな状況は完了時間を決定するために重要です。
「ループ」を推定して再試行回数を意味する場合、これは使用するパラメータによって決まります。 「総パス数」を意味する場合は、ここでアルゴリズムを読むと簡単に確認できます。 > man ddrescue </アルゴリズム：ddrescueがデータを回復する方法
提供されたスクリーンショットの数字について具体的に議論します。他の状況では異なる要因が適用される可能性があるため、この情報を一般的なガイドラインとして使用してください。
提供された例で、ddrescueの実行ステータス画面を確認してください。私たちは、「errsize」を通じて問題（構造ドメイン）の完全な「推定」を取得します。これは「未読」データの量です。例では345GBです。右下の行は「平均金利」です。例では、583kb/s
「平均比率」が安定している場合、これは7日間残ります。 345GB / (583kb * 60*60*24) = 7.18 しかし、問題は583kb/sに依存できないということです。実際、ドライブはより困難な領域を読み取ってより多くの再試行を行うため、回復が進むにつれて速度が遅くなります。そのため、完了時間が指数関数的に増えます。これらすべては、ドライブの損傷の重大度によって異なります。
提供された例は、「読み取り成功」が10時間以上経過したことを示しています。つまり、実際には10時間以上ドライブから情報を取得できませんでした。これは、ドライブに345 GBのデータ（またはその一部）がある可能性があることを示します。これはあなたにとって非常に悪いニュースです。
これとは対照的に、2番目の500 GBドライブでは、ディスクにコピー中に「SMART」エラーが発生し始めました（ログファイルは別のドライブにあります）、全体の操作に約8〜9時間かかりました。最後の部分が遅くなりました。しかし、まだ耐えるだけです。前述のように、非常に悪いドライブは2週間で500 GBで動作し、まだ回復可能な部分は4〜5％残ります。
HTHとYMMV