ddrescueを高速化する方法はありますか？

約5日前に500GBドライブの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（一度再試行する）と共に使用し、（-cクラスターサイズ）をより小さい値に設定すると役立つことがわかった。

私の印象ではddrescue、破損した領域を分割して再び分割するため、分割ステップは非常に遅いということです。ddrescueデータのごく一部を復元しようとするため、これには時間がかかります。だから、私は使用しないことを好む-nと一緒に（無分割）-c 64、-c 32、-c 16、阿蘇

おそらく、-n（分割されていない）順方向と逆方向の最初の1回のパスに常に使用する必要があります。これについてはわかりませんが、データが分割されるほど、クローン作成は遅くなります。ddrescueより多くの連続したセクターがクローンを作成するため、未処理の領域が大きいほど、再実行時に最適であると想定します。

ログファイルを使用しているので、データの読み取り速度が2つ遅くなったときにCtrl+でコマンドをキャンセルすることをheしませんC。

また、-R（リバース）モードを使用します。最初のパスの後、しばしば前方よりも後方を読む速度が速くなります。

コマンドを再度-r N実行するddrescueとき、特に順方向（デフォルト）と逆方向（-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実行中に使用することもできます...

ddrescueの進行状況を監視するもう1つの方法（少なくともLinuxでは）は、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個の値を取得できるように、「head」にパイピングしました。

root@mojo:~# strace -p 4073 2>&1 | grep lseek | head

これが誰かを助けることを願っています。

データの大部分をそのまま取得することを目的とする場合は、抽出を高速化できます。しかし、可能な限り多くのデータを実際に救いたい場合は、ddrecueニブルをすべての場所で使用できるようにします。

-Kパラメーターを使用すると、速度を上げることができることがわかりました。-nオプションを指定して実行したときにddrescueがエラーを検出した場合に見たものから、一定量のセクターをジャンプしようとします。それでも読み取れない場合は、サイズが2倍にジャンプします。大きな損傷領域がある場合は、大きなK値（たとえば100M）を示すことができるため、エラーのジャンプは最初に大きくなり、最初の過去に問題のある領域をすばやく回避することが容易になります。

ところで、ログを分析するためのすばらしいグラフィカルアプリケーションがあります。

http://sourceforge.net/projects/ddrescueview/

レスキューイメージとログファイルを保存するハードディスクのファイルシステムは何ですか？USBスティックからLinux Mintを実行しているラップトップで500GBの内部ハードドライブ（SATA経由で接続）をレスキューし、レスキューイメージとログファイルをexFatフォーマット済みのUSBハードドライブに保存すると、かなりゆっくりと開始します（1-2MB /秒）が、約250 GBの後、クロールは100 KB /秒未満でした。レスキューイメージファイルが大きくなるほど遅くなるように見えました。

その後、レスキューイメージとログファイルを別の一時的な場所に移動し、ext4ファイルシステムでUSBハードドライブを再フォーマットし、ファイルを元に戻し、ddrescueプロセスを再開しました。しかし、平均で約7MB /秒）！

exFat非常に大きなファイル（数百ギガバイト）ではうまく再生できないようです。

ディスクをレスキューするためのより高速で迅速なオプションとして、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を1回使用すると、完了後に-Rを使用できます。これにより、すべてのエラーサイズが元に戻されて削除され、逆方向に再び開始されます。エラーを異なる方法で読み取ることを意味します。

dd_rhelpはdd_rescueを使用するシェルスクリプトです。「[...]ディスク全体で、ただし、不良セクタの束で年齢を試す前に最大有効データを収集しようとします」

かなり古い（2012）が、まだ機能している。まだddrescueを試していません。