web-dev-qa-db-ja.com

ddrescueプロセスを再開する方法?

1 TBのUSB HDを復元する必要があります。これを達成するためにddrescueを使用しています。開始したらddrescueを再開できる方法はありますか?

私は次のコマンドを使用しています:

ddrescue /dev/sdd1 ./bye1t.dd_rescue.image
9
confiq

ddrescueは再開できますが、再開するにはログファイルが必要です。ログファイルはddrescueがこれまでに行った進行状況を記録し、ddrescueを再起動するとログファイルが読み取られ、中断したところから開始されます。

ログファイルは3番目のパラメータになります。

ddrescue /dev/sdd1 ./bye1t.dd_rescue.image ~/sdd1.log

ログファイルなしですでにddrescueの実行を開始し、それをキャンセルした場合、次回のddrescueの実行時には、すでに回復されたものの記録がないため、最初から開始されます。

ddrescuedd_rescue は異なるプログラムです。

14
shf301

ログファイルを指定するのを忘れたとしても、希望があるかもしれません:

生成モード

したがって、チュートリアルを読んでおらず、ログファイルなしでddrescueを開始しました。さて、2日後、コンピュータがクラッシュし、ddrescueがどれだけのデータを保存できたかがわかりません。さらに悪いことに、救助を再開することはできません。最初からやり直す必要があります。

または、dd conv=noerror,syncを使用してドライブのコピーを開始し、上記と同じ状況になっている可能性があります。この場合、sync変換引数を指定して呼び出されない限り、ddによって作成されたコピーを使用できないことに注意してください。

(まだ)絶望しないでください。 Ddrescueは、場合によっては、入力ファイルと(部分的な)コピーから、正確なログファイルとほぼ同じくらいの近似ログファイルを生成できます。これは、すべてのゼロを含むセクターが救出されなかったと単純に仮定することによってこれを行います。

ただし、コピーの宛先がドライブまたはパーティションである場合(または既存の通常のファイルであり、切り捨てが要求されていない場合)、おそらく最初からddrescueを再起動する必要があります。 (もちろん、今回はログファイルを使用します)。その理由は、まだ上書きされていない古いデータがドライブに存在する可能性があり、そのため、未試行でゼロではない可能性があるためです。

たとえば、最初に次のコマンドのいずれかを試した場合:

ddrescue infile outfile

または

dd if=infile of=outfile conv=noerror,sync

次のコマンドでおおよそのログファイルを生成できます:

ddrescue --generate-mode infile outfile logfile
6
Miles Wolbe

他の人が言ったように、再開を許可する3番目のパラメーターとして常にログファイルを指定する必要があります。あなたはそれをしなかったので、それはここではあなたを助けにはなりません。プロセスがどのポイントに到達したかがおおよそわかっている場合は、--input-positionおよび--output-positionパラメータをその時点から開始します(これらのパラメータを両方とも同じ値に設定してください。そうしないと、出力が破損します)。

3
mgorven

ログファイルを3番目のパラメータとして指定しなかったため、再開を自動的に行うことはできません。すでに救出されたセクターを知っていれば、手作業でログファイルを作成でき、構文は簡単です。ログを指定しながら別のダミーレスキューを開始して、別の領域を読み取らせるだけです。次に、ログを編集して、最初のファイルですでに救出された領域を表します。ここで前のコマンドを再実行しますが、3番目のパラメーターとしてログファイルの名前を指定します。 ddrescueは、最初の未試行のセクターで再開します。

2
Gurken Papst

https://wiki.archlinux.org/index.php/Disk_cloning によると、conv=noerror,syncスイッチを使用すると、実際にdddoesにゼロが追加されますブロックの最後で、読み取りエラーが発生した正確な場所ではありません。これは、2013-08-29からのMiles Wolbeの回答の情報に反しています。

たとえば、正しいシーケンスが198123283で、途中で読み取りエラーが発生した場合、198283000ではなく198000283が書き込まれます。

そのため、実際に読み取りエラーが発生した場合、提案された方法は正確ではありません-ゼロで埋められる読み取り可能な領域がありますが、「救出された」と見なされます。

ちなみに、復元先ドライブにゼロ(または、少なくともWinHexで実行できる空き領域など)を入力して、このような回復を試みることをお勧めします。

2
GabrielB