如何使用目前狀態估計完成 GNU ddrescue (1.18.1) 的循環/時間？
背景/上下文：
我目前正在執行 GNU ddrescue 1.18.1 以從 USB 恢復數據，當我將虛擬磁碟映像寫入 disk2s1 分區時遇到電纜斷開連接。最初我正在恢復我的第二個分區（disk2s2），並註意到我已經進入了第三階段（拆分）。我將圖像放置到網路儲存中。
問題：
我注意到這個階段循環。鑑於我目前的狀態資訊（我只顯示兩個錯誤），有沒有辦法計算我可能遇到的循環數？
地位：
更新/編輯：
所以我仍然對如何使用 ddrescue 工具估計完成的循環/時間非常感興趣。根據評論，我正在為我的 disk2s1 分區添加一個日誌文件評估，因為它目前正在執行（disk2s2 在 14.5 小時後完成，一個使用者中斷了大約 6 小時）。
完成的分區日誌
對於剛剛完成的分區，這裡是日誌檢查的結果。
參考（ddrescue算法筆記）：
4 算法
GNU ddrescue 不是 dd 的衍生物，也與 dd 沒有任何關係，只是兩者都可以用於將數據從一個設備複製到另一個設備。主要區別在於 ddrescue 使用複雜的算法從故障驅動器中複製數據，從而盡可能減少對它們造成的額外損害。
Ddrescue 有效地管理救援進行中的狀態，並嘗試首先救援好的部分，然後安排在壞（或慢）區域內的讀取以供以後使用。這最大限度地提高了最終可以從故障驅動器中恢復的數據量。
標準 dd 實用程序可用於保存故障驅動器中的數據，但它會按順序讀取數據，如果錯誤出現在驅動器的開頭，這可能會磨損驅動器而無法挽救任何東西。
其他程序按順序讀取數據，但在發現錯誤時切換到小尺寸讀取。這是一個壞主意，因為這意味著在錯誤區域花費更多時間，損壞表面、磁頭和驅動機制，而不是盡快擺脫它們。這種行為減少了挽救剩余良好數據的機會。
ddrescue 的算法如下（使用者可以隨時中斷程序，但要注意壞的驅動器會阻塞 ddrescue 很長時間，直到核心放棄）：
- 可選擇讀取描述多部分或先前中斷救援狀態的日誌文件。如果未指定日誌文件或為空或不存在，則將所有救援域標記為未嘗試。
2）（第一階段；複製）讀取輸入文件中未嘗試的部分，將失敗的塊標記為未修剪並跳過它們。也跳過慢速區域。跳過的區域稍後在兩次額外的通道中嘗試（在修剪之前），每次通道後反轉方向，直到嘗試所有救援域。第三次傳球是橫傳，禁跳。（目的是快速界定大錯誤，保持日誌文件小，並產生良好的修剪起點）。僅以大塊讀取未嘗試的區域。修剪、拆分和重試是逐個扇區完成的。每個扇區最多嘗試兩次；此步驟中的第一個（通常作為大塊讀取的一部分，但有時作為單扇區讀取），以下步驟之一中的第二個作為單扇區讀取。
3）（第二階段；修剪）從最小的未修剪塊的前沿一次讀取一個扇區，直到找到壞扇區。然後從同一塊的後沿一次向後讀取一個扇區，直到找到壞扇區。對於每個未修剪的塊，將找到的壞扇區標記為壞扇區，並將該塊的其餘部分標記為未拆分，而不嘗試讀取它。重複直到沒有更多未修剪的塊。（大的未修剪塊是由較小的塊連接產生的，因此它在邊緣的好數據比例較小）。
4）（第三階段；拆分）從最大的非拆分塊的中心一次讀取一個扇區，直到找到壞扇區。然後，如果找到的壞扇區不是第一個嘗試的，則從同一塊的中心一次向後讀取一個扇區，直到找到壞扇區。如果日誌文件大於“–logfile-size”，則順序讀取最大的非拆分塊，直到日誌文件中的條目數低於“–logfile-size”。重複直到所有剩餘的非分割塊少於 7 個扇區。然後依次讀取剩餘的非拆分塊。
5）（第四階段；重試）可選地嘗試再次讀取壞扇區，直到達到指定的重試次數。每個壞扇區在每次通過時只嘗試一次。Ddrescue 無法知道壞扇區是否不可恢復，或者在重試後是否最終會被讀取。
- 可選地寫一個日誌文件供以後使用。
總錯誤大小 (’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 日誌文件
儘管這個問題是在 10 個月前提出的，但答案可能是相關的，因為恢復週期可能仍在執行，這取決於幾個因素！沒有雙關語的意思。
原因是，時間估計幾乎是不可能的，但有時您可以大致了解如下。最明顯的原因之一是您無法預測驅動器讀取壞扇區需要多長時間，如果您希望 ddrescue 讀取並重試每個扇區，則可能需要很長時間。例如，我目前正在一個 500GB 的小型驅動器上執行恢復，該驅動器已經執行了 2 週多，我可能還剩下幾天。但我的情況更複雜，因為驅動器已加密並且要成功讀取任何內容，我必須確保獲取所有具有分區表、引導扇區和磁碟其他重要部分的扇區。除了 ddrescue 之外，我還使用技術來提高我對所有壞扇區的機會。愛荷華州，
通過估計“循環”，如果您的意思是重試次數，那麼這是您通過使用的參數確定的。如果您的意思是“通過的總數”，這很容易通過閱讀此處的算法來確定。 >man ddrescue</ 算法：ddrescue 如何恢復數據
我將特別談談您提供的螢幕截圖中的數字。其他情況可能有其他適用因素，因此請將此資訊作為一般指南。
在您提供的範例中，查看 ddrescue 的執行狀態螢幕。我們通過“errsize”得到問題（救援域）的總“估計”。這是“尚未讀取”的數據量。在範例中為 345GB。右下方的下一行是“平均比率”。在範例中為 583kb/s
如果“平均利率”保持接近穩定，這意味著您還有 7 天的時間。345 GB / (583 kb * 606024) = 7.18 但是問題是你不能依賴 583kb/s。實際上，您進入恢復的深度越深，驅動器就越慢，因為它正在讀取越來越多的困難區域並且正在進行更多的重試。所以完成的時間成倍增加。所有這一切都取決於驅動器損壞的嚴重程度。
您提供的範例顯示“成功讀取”是 10 多個小時前。也就是說，它在 10 多個小時內並沒有真正從驅動器中得到任何東西。這表明您的驅動器可能有 345GB 的數據（或一部分）。這對你來說是個壞消息。
相比之下，我的第二個 500GB 驅動器剛剛開始出現“SMART”錯誤，被複製到磁碟（在另一個驅動器上帶有日誌文件），整個操作大約需要 8-9 小時。它的最後一部分放慢了速度。但這仍然可以忍受。雖然如上所述的非常糟糕的驅動器在 500GB 上工作了 2 週，但仍有大約 4-5% 的剩餘空間需要恢復。
HTH 和 YMMV