約 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...
答え1
(no-split) オプションを(retry once)-nと一緒に使用し、 (cluster size) を小さい値に設定すると役立つことがわかりました。-r 1-c
私の印象では、分割ステップは、損傷した領域を分割して再度分割するため、非常に遅いです。これは、データの非常に小さな部分を復元しようとするddrescueため、時間がかかりますddrescue。そのため、私は、、、、-nと一緒に (no-split)を使用することを好みます。-c 64-c 32-c 16
おそらく、-n(分割なし) は、順方向と逆方向の最初の 1 回のパスでは常に使用する必要があります。データが分割されるほど、クローン作成が遅くなるようですが、これについてはよくわかりません。処理されていない領域が大きいほど、ddrescueクローン作成する連続セクターが増えるため、再度実行するときに最適であると考えられます。
ログファイルを使用しているため、データの読み取り速度が遅くなった場合は、躊躇せずにCtrl+でコマンドをキャンセルします。C
私は (逆) モードも使用しており-R、最初のパスの後は、順方向よりも逆方向の読み取り速度が速くなることがよくあります。
-r Nコマンドを再度実行する場合ddrescue、特に順方向 (デフォルト) と逆方向 ( ) のクローン作成コマンドを交互に実行する場合、すでに再試行されたセクター ( ) がどのように処理されるのか私には-Rわかりません。試行された回数がログファイルに保存されるかどうかはわかりませんが、おそらく作業は無駄に再度実行されるでしょう。
おそらく、-i(入力位置) フラグも速度向上に役立ちます。
答え2
の進行状況を確認するのは非常に難しい場合があります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実行中でも使用できます...
答え3
-K パラメータをいじってみると、処理速度が上がることがわかりました。私が見た限りでは、ddrescue が -n オプションで実行中にエラーを見つけると、一定数のセクターをジャンプしようとします。それでも読み取れない場合は、サイズを 2 倍にしてジャンプします。大きな損傷領域がある場合は、大きな K 値 (たとえば 100M) を指定すると、エラー発生時のジャンプが初回は大きくなり、最初のうちは問題のある領域をすばやく回避しやすくなります。
ちなみに、ログを分析するための素晴らしいグラフィカル アプリケーションがあります。
答え4
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 と競合するため、おそらく悪い計画です。私はこれを "head" にパイプして、最初の 10 個の値を取得できるようにしました。
root@mojo:~# strace -p 4073 2>&1 | grep lseek | head
これが誰かの役に立つことを願います。