ddrescueを高速化する方法はありますか？
約5日前に500 GBドライブのHDDクラッシュが発生しました。数日前に重要なパーティションでddrescueを使用しましたが、「障害ブロックのトリミング」が約2日間続いています。
元のコマンド：
ddrescue -n /dev/rdisk1s2 /Volumes/OSXBackup/rdisk1s2.img /Volumes/OSXBackup/rdisk1s2.log
現在の出力：
Initial status (read from logfile)
rescued: 248992 MB, errsize: 1007 MB, errors: 15867
Current status
rescued: 249021 MB, errsize: 978 MB, current rate: 17408 B/s
ipos: 44405 MB, errors: 15866, average rate: 2784 B/s
opos: 44405 MB, time from last successful read: 0 s
Trimming failed blocks...
元のコマンドはddrescue -nパラメーターを使用し、必要に応じてプロセスを数回再起動しました（そして、毎回中断したところから再開したようです）。
このプロセスをスピードアップする方法はありますか？
編集： 6時間後、これが現在のステータスです。
rescued: 249079 MB, errsize: 920 MB, current rate: 409 B/s
ipos: 39908 MB, errors: 15851, average rate: 2698 B/s
opos: 39908 MB, time from last successful read: 0 s
Trimming failed blocks...
「エラー」が非常にゆっくりとカウントダウンしている間、ipos/oposはチャーンする必要があるデータの量をカウントダウンしており、750MB /時の速度で動作しているようです。このレートでは、約53時間で完了します。うわぁ。
編集＃2： 2日後、まだ実行中です。しかし、希望はあります。 「失敗したブロックのトリミング」の部分を通過し、次のフェーズ「失敗したブロックの分割」に移行しました。どちらかといえば、この質問を表示しないようにする必要があるのは、かなりの量のデータ/エラーが含まれている場合、これには間違いなく長い時間がかかるということです。私の唯一の望みは、すべての発言が完了したときに、いくつかの重要なデータを正常に回復できることです。
rescued: 249311 MB, errsize: 688 MB, current rate: 0 B/s
ipos: 26727 MB, errors: 15905, average rate: 1331 B/s
opos: 26727 MB, time from last successful read: 20 s
Splitting failed blocks...
-n（分割なし）オプションを-r 1（1回再試行）と共に使用し、-c（クラスターサイズ）を小さい値に設定すると役立つ場合があることを確認しました。
ddrescueが分割され、破損した領域が再び分割されるため、分割ステップは非常に遅いと思います。 ddrescueはデータのごく一部を復元しようとするため、これには長い時間がかかります。そのため、-n（分割なし）を-c 64、-c 32、-c 16、a.s.oと組み合わせて使用することを好みます。
おそらく-n（スプリットなし）は常に、順方向と逆方向の最初の1つのパスに使用する必要があります。これについてはよくわかりませんが、データが分割されるほど、クローン作成が遅くなったようです。連続するセクターのクローンを作成する必要があるため、未処理の領域が大きいほど、ddrescueを再度実行するときに最適になると思います。
私はログファイルを使用しているので、コマンドをキャンセルすることを躊躇しません Ctrl+C データの読み取り速度が2つに低下したとき。
私は-R（リバース）モードも使用しており、最初のパスの後、多くの場合、フォワードよりもバックワードの読み取り速度が速くなります。
ddrescueコマンドを再度実行するとき、特にフォワード（デフォルト）とリバース（-r N）のクローンコマンドを交互に実行するときに、すでに再試行されたセクター（-R）がどのように処理されるかは明確ではありません。試行された回数がログファイルに保存されているかどうかはわかりませんが、おそらく作業は無駄に行われます。
おそらく-i（入力位置）フラグも物事をスピードアップするのに役立ちます。
ddrescueの進行状況を確認するのは非常に困難ですが、ddrescuelogと呼ばれる別のコマンドが含まれています。
簡単なコマンドddrescuelog -t YourLog.txtはこれらのニース情報を出力します：
current pos: 2016 GB, current status: trimming
domain size: 3000 GB, in 1 area(s)
rescued: 2998 GB, in 12802 area(s) ( 99.91%)
non-tried: 0 B, in 0 area(s) ( 0%)
errsize: 2452 MB, errors: 12801 ( 0.08%)
non-trimmed: 178896 kB, in 3395 area(s) ( 0.00%)
non-split: 2262 MB, in 9803 area(s) ( 0.07%)
bad-sector: 10451 kB, in 19613 area(s) ( 0.00%)
ddrescueの実行中にも使用できます...
-Kパラメーターを使用すると、処理を高速化できることがわかりました。 -nオプションを指定して実行しているときにddrescueがエラーを検出した場合、私が見てきたことから、一定量のセクターをジャンプしようとします。それでも読み込めない場合は、サイズが2倍になります。大きな損傷領域がある場合は、大きなK値（たとえば100M）を示すことができるため、エラーのジャンプは初めて大きくなり、問題のある領域を最初からすばやく回避するのが簡単になります。
ちなみに、ログを分析する素晴らしいグラフィックアプリケーションがあります。
（少なくともLinuxでは）ddrescueの進行状況を監視するもう1つの方法は、straceを使用することです。
まず、「ps aux | grep ddrescue」を使用してddrescueプロセスのPIDを見つけます
root@mojo:~# ps aux | grep ddrescue
root 12083 0.2 0.0 15764 3248 pts/1 D+ 17:15 0:04 ddrescue --direct -d -r0 /dev/sdb1 test.img test.logfile
root 12637 0.0 0.0 13588 940 pts/4 S+ 17:46 0:00 grep --color=auto ddrescue
次に、そのプロセスに対して「strace」を実行します。次のようなものが表示されます。
root@mojo:~# strace -p 12083
Process 12083 attached - interrupt to quit
lseek(4, 1702220261888, SEEK_SET) = 1702220261888
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(3, 1702220261376, SEEK_SET) = 1702220261376
read(3, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(4, 1702220261376, SEEK_SET) = 1702220261376
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
^C
...等々。出力は高速で見苦しいので、「grep」を介してパイプし、気になるものを除外します。
root@mojo:/media/u02/salvage# Nice strace -p 12083 2>&1|grep lseek
lseek(4, 1702212679168, SEEK_SET) = 1702212679168
lseek(3, 1702212678656, SEEK_SET) = 1702212678656
lseek(4, 1702212678656, SEEK_SET) = 1702212678656
lseek(3, 1702212678144, SEEK_SET) = 1702212678144
lseek(4, 1702212678144, SEEK_SET) = 1702212678144
lseek(3, 1702212677632, SEEK_SET) = 1702212677632
lseek(4, 1702212677632, SEEK_SET) = 1702212677632
lseek(3, 1702212677120, SEEK_SET) = 1702212677120
lseek(4, 1702212677120, SEEK_SET) = 1702212677120
lseek(3, 1702212676608, SEEK_SET) = 1702212676608
^C
この例では、「1702212676608」は「回収しようとしている2 Tbディスクでまだ処理する必要があるデータの量」に相当します。 （うん、痛い。）ddrescueは、画面出力で「1720 GB」とはいえ、似たような数値を吐き出しています。
straceを使用すると、非常に高い粒度のデータストリームを確認できます。それはddrescueの速度を評価し、完了日を推定するもう1つの方法です。
CPU時間のddrescueと競合するため、絶えず実行することはおそらく悪い計画です。最初の10個の値を取得できるように、それを「ヘッド」にパイピングすることにしました。
root@mojo:~# strace -p 4073 2>&1 | grep lseek | head
これが誰かを助けることを願っています。
データの大部分をそのまま取得することを目的としている場合は、その抽出を高速化できます。しかし、本当に可能な限り多くのデータを救いたいのであれば、ddrecueをニブルに任せるのが、たどる道です。
レスキューイメージとログファイルを保存するハードディスクのファイルシステムは何ですか？ Linux Mintを実行しているラップトップで500GB内蔵ハードドライブ（SATA経由で接続）をUSBスティックから救出し、レスキューイメージとログファイルをexFatフォーマットのUSBハードドライブに保存して、ゆっくり（1〜2 MB /秒）ですが、約250 GBの後は100 KB /秒未満でのみクロールしていました。レスキュー画像ファイルが大きくなるほど遅くなるように見えました。
次に、レスキューイメージとログファイルを別の一時的な場所に移動し、ext4ファイルシステムでUSBハードドライブを再フォーマットし、ファイルをその上に戻し、ddrescueプロセスを再開しました。これで、1〜20 MBで実行されます/秒（変動しますが、平均で約7MB /秒）！
exFatは、非常に大きなファイル（数百ギガバイト）ではうまく機能しないようです。
dd_rhelp は、ディスク全体でdd_rescue "[...]を使用するシェルスクリプトですが、不良セクターの束で年齢を試す前に、有効な最大データを収集しようとします"
それはかなり古い（2012）ですが、まだ動作します。まだddrescueを試していません。
ディスクをレスキューするためのより高速で迅速なオプションとして、shスクリプトファイルを使用して、「sh filename.sh」でファイルを実行できます。表示されているこの行が含まれています。「Sudo ddrescue」と「sleep 3」をさらに数回繰り返すだけです。スリープは、ドライブを数秒休ませるために使用されます。これは、いくつかの理由で良い場合があります。
#! /bin/sh -e
Sudo ddrescue -d -r0 -e +0 -T 1s -n /dev/drivepartition file.img log.logfile
sleep 3
-r0には応答がありません。 -e +0は、1つのエラーで終了するためのものです。 -T 1sは、1秒の読み取り失敗で終了します。直接の場合は-dとして使用でき、速度を上げることができるスクレイプなしの場合は-nとして使用できるオプションがあります。
オプション-Aで終了後に-Rを1回使用すると、すべてのエラーサイズが反転して削除され、逆方向に再び開始されます。エラーを別の方法で読み取ることを意味します。