現在のステータスを使用して、GNU ddrescue（1.18.1）の完了までのループ/時間を推定するにはどうすればよいですか？

背景/コンテキスト：

私は現在、GNU ddrescue 1.18.1を実行して、disk2s1パーティションに仮想ディスクイメージを書き込んでいる間にケーブルが切断されたUSBからデータを回復しています。最初は2番目のパーティション（disk2s2）を回復していて、3番目のフェーズ（分割）に達したことに気付きました。イメージをネットワークストレージに配置しています。

質問：

このフェーズがループすることに気づきました。現在のステータス情報から、発生する可能性が高いループの数を計算する方法はありますか？

状態：

更新/編集：

ですから、ddrescueツールを使用して、ループ/完了の時間をどのように推定できるかについては、まだ非常に興味があります。コメントに従って、現在実行中のdisk2s1パーティションのログファイルの評価を追加しています（disk2s2は14.5時間後に完了し、1人のユーザーが約6時間中断しました）。

完了したパーティションログ

完了したばかりのパーティションについて、ログ検査の結果を次に示します。

リファレンス（ddrescueアルゴリズムの注意）：

4アルゴリズム

GNU ddrescueはddの派生物ではありません。また、あるデバイスから別のデバイスにデータをコピーするために両方を使用できるという点を除いて、ddとは関係ありません。主な違いは、ddrescueは高度なアルゴリズムを使用して、故障したドライブからデータをコピーし、追加の損傷をできるだけ少なくすることです。

Ddrescueは進行中のレスキューのステータスを効率的に管理し、最初に適切な部分をレスキューしようとし、後で悪い（または遅い）領域内の読み取りをスケジュールします。これにより、故障したドライブから最終的に回復できるデータの量が最大になります。

標準のddユーティリティを使用して、障害が発生したドライブからデータを保存できますが、データが順次読み取られるため、ドライブの先頭にエラーがある場合は、ドライブを使い果たすことなく何も救うことができません。

他のプログラムはデータを順番に読み取りますが、エラーが見つかった場合は小さいサイズの読み取りに切り替えます。これは、エラー領域でより多くの時間を費やし、できるだけ早くそれらから抜け出すのではなく、表面、ヘッド、およびドライブ機構に損傷を与えることを意味するため、これは悪い考えです。この動作により、残りの適切なデータを救う可能性が減少します。

ddrescueのアルゴリズムは次のとおりです（ユーザーはいつでもプロセスに割り込むことができますが、不良ドライブがカーネルが停止するまでddrescueを長時間ブロックする可能性があることに注意してください）。

1）オプションで、マルチパートまたは以前に中断されたレスキューのステータスを説明するログファイルを読み取ります。ログファイルが指定されていないか、空または存在しない場合は、すべてのレスキュードメインを未試行としてマークします。

2）（最初のフェーズ;コピー）入力ファイルの未試行部分を読み取り、失敗したブロックを非トリムとしてマークし、それらを超えてスキップします。遅いエリアを越えてスキップします。スキップされた領域は、後で2つの追加パス（トリミング前）で試行され、すべてのレスキュードメインが試行されるまで、各パスの後で方向が逆になります。3番目のパスは、スキップを無効にしたスイープパスです。（目的は、大きなエラーをすばやく区切り、ログファイルを小さく保ち、トリミングの開始点を作成することです）。未試行の領域のみが大きなブロックで読み取られます。トリミング、分割、再試行はセクターごとに行われます。各セクターは最大2回試行されます。このステップの最初は（通常、大きなブロックの読み取りの一部として、場合によっては単一セクターの読み取りとして）、以下のステップの1つで2番目は単一セクターの読み取りとして。

3）（第2フェーズ、トリミング）読み取りは、トリミングされていない最小のブロックのリーディングエッジから、不良セクターが見つかるまで、一度に1セクターずつ転送します。次に、不良ブロックが見つかるまで、同じブロックの後縁から一度に1セクターずつ逆方向に読み取ります。トリミングされていないブロックごとに、見つかった不良セクターを不良セクターとしてマークし、そのブロックの残りの部分を、読み取ろうとせずに非分割としてマークします。トリミングされていないブロックがなくなるまで繰り返します。（トリミングされていない大きなブロックは、小さいブロックを連結することによって生成されるため、エッジでの適切なデータの割合は小さくなります）。

4）（第3段階;分割）読み取りは、最大の非分割ブロックの中心から一度に1つのセクターを、不良セクターが見つかるまで転送します。次に、見つかった不良セクターが最初に試行したものでない場合は、不良セクターが見つかるまで、同じブロックの中心から一度に1セクターずつ逆方向に読み取ります。ログファイルが「--logfile-size」よりも大きい場合、ログファイルのエントリ数が「--logfile-size」を下回るまで、最大の非分割ブロックを順番に読み取ります。残りのすべての非分割ブロックのセクターが7未満になるまで繰り返します。次に、残りの非分割ブロックを順番に読み取ります。

5）（第4フェーズ;再試行）オプションで、指定された再試行パスの回数に達するまで、不良セクターの読み取りを再試行します。すべての不良セクターは、各パスで1回だけ試行されます。Ddrescueは、不良セクターが回復不能であるかどうか、または再試行後に最終的に読み取られるかどうかを知ることができません。

6）オプションで、後で使用するためにログファイルを書き込みます。

合計エラーサイズ（ 'errsize'）は、すべての非トリミングブロック、非分割ブロック、および不良セクターブロックのサイズの合計です。コピーフェーズ中に増加し、トリミング、分割、再試行中に減少する可能性があります。ddrescueが失敗したブロックを分割してそれらを小さくすると、エラーの数が増加する一方で、合計エラーサイズが減少する可能性があることに注意してください。

ログファイルは定期的にディスクに保存されます。また、ddrescueが終了したときや中断されたときも保存されます。したがって、クラッシュが発生した場合は、ほとんど再コピーせずにレスキューを再開できます。保存の間隔は、ログファイルのサイズに応じて30秒から5分まで変化します（大きなログファイルはより長い間隔で保存されます）。

また、同じログファイルを、入力ファイルの異なる領域をコピーする複数のコマンド、および異なるサブセットでの複数のリカバリ試行に使用できます。この例を見てください：

まず、ディスクの最も重要な部分を救出してください。ddrescue -i0 -s50MiB / dev / hdc hdimage logfile ddrescue -i0 -s1MiB -d -r3 / dev / hdc hdimage logfile

次に、いくつかの重要なディスク領域を救出します。ddrescue -i30GiB -s10GiB / dev / hdc hdimage logfile ddrescue -i230GiB -s5GiB / dev / hdc hdimage logfile

ここで残りを救い出します（すでに行われたことを再コピーしません）。ddrescue / dev / hdc hdimage logfile ddrescue -d -r3 / dev / hdc hdimage logfile

質問は10か月前に行われましたが、いくつかの要因によっては回復サイクルがまだ実行されている可能性があるため、回答は適切である可能性があります。しゃれは意図されていません。

その理由は、時間の見積もりはほとんど不可能ですが、次のような大まかなアイデアが得られる場合があるためです。最も明白な理由の1つは、ドライブが不良セクターを読み取るのにかかる時間を予測できないことです。ddrescueですべてのセクターを読み取って再試行する場合、非常に長い時間がかかる可能性があります。たとえば、現在2週間以上続いている小さな500 GBドライブでリカバリを実行していて、残り数日しかない可能性があります。しかし、ドライブは暗号化されており、正常に何かを読み取るために、パーティションテーブル、ブートセクター、およびディスクの他の重要な部分があるすべてのセクターを取得するようにしています。私はddrescueに加えてテクニックを使用して、すべての不良セクターの可能性を高めています。IOW、

「ループ」の見積もりでは、再試行の回数を意味する場合、それは使用するパラメーターによって決まります。「パスの総数」を意味する場合は、ここでアルゴリズムについて読むことで簡単に判断できます。 > man ddrescue </アルゴリズム：ddrescueがデータを回復する方法

具体的には、ご提供いただいた画面キャプチャの数字についてお話します。他の状況には他の要素が適用される可能性があるため、この情報を一般的なガイドラインとして使用してください。

提供したサンプルでは、​​ddrescueの実行ステータス画面を確認してください。「errsize」により、問題（レスキュードメイン）の合計「見積もり」を取得します。これは、「まだ読み取られていない」データの量です。サンプルでは345GBです。右下の次の行は「平均レート」です。サンプルでは583kb / sです

「平均レート」がほぼ安定したままであるとすると、これはあと7日残っていることを意味します。345 GB /（583 kb * 60 * 60 * 24）= 7.18ただし、問題は583kb / sに依存できないことです。実際には、回復に入るまでの時間が長くなるほど、ドライブはますます厳しい領域を読み取り、再試行の回数が増えるため、速度が低下します。したがって、指数関数的に終了する時間が増加します。これはすべて、ドライブがどれほどひどく破損しているかによって異なります。

あなたが提供したサンプルは、「正常な読み取り」が10時間以上前であったことを示しています。つまり、ドライブから10時間以上何も取得されていません。これは、ドライブに345GB相当（または一部）のデータショットがある可能性があることを示しています。これはあなたにとって非常に悪いニュースです。

対照的に、「SMART」エラーが発生し始めた2番目の500 GBドライブはディスクにディスクにコピーされ（ログファイルは別のドライブにあります）、操作全体に約8〜9時間かかりました。それの最後の部分は減速しました。しかし、それはまだ耐えられます。非常に不良なドライブですが、上記のように、500GBで2週間作業し過ぎており、回復するのに約4〜5％残っています。

HTHおよびYMMV