ddコマンドを使用したのは今回が初めてです。私は次を実行します：
dd if=/dev/sdb2 of=/mnt/sdc1/Hdd1.img bs=512 conv=noerror,sync
ここで、sdbは破損したハードドライブ（サイズ：500GB）です。 sdb2パーティションをイメージにコピーしました。私はこれを6（！）日間やっている。 imgサイズは約640GBで、まだ計算中です（例：まだ完了していません...）。 6日後、コピーされたデータの詳細（バイトがコピーされた宛先）は印刷され、停止されません。
普通ですか？ imgサイズが破損したハードドライブのフルサイズよりどのように大きいのですか？いつ完了すると予想されますか？
答え1
一度に512バイトをコピーすると、多数の読み書きが行われます。計算してみると実際には1000億程度になります。また、同期をリクエストしています。 [編集：oflag=sync次のステートメントは無効ではありません。]これは、返す前に各書き込みが実際にディスクに書き込まれるのを待つことを意味します。ディスク速度が非常に速いので、各書き込みに2ミリ秒かかるとしましょう。
500GB / 512バイト* 2ミリ秒= 22.6日。
と、水槽ミリ秒の時間が早く合わさってますね、そうでしょ？
[編集：これは実際に興味深い数学ですが、oflag=sync使用されていないので正確ではありません。不良セクタの繰り返し読み出しと関連するタイムアウトにより遅延が発生する可能性が高い。以下のdd_rescueメソッドは大きな助けになります。大きなブロックサイズの通常のddを使用すると役に立ちますが、読み取りサイズを変更できず、大きな損傷をスキップできないため、あまり多くありません。 ]
より大きなブロックサイズを使用するか、同期をスキップするとより速く実行されます。
# dd if=/dev/sdb2 of=/sdb2-image.img bs=1024k
sdb2 イメージから読み取るときに読み取りエラーが懸念される場合は、-A オプションを指定して dd_rescue を使用して書き込みをスキップするのではなく、0 ブロックを書き込みます。間違ったブロックを完全にスキップすると、一部のファイルシステム構造が元のオフセットとは異なるオフセットに現れるときに問題が発生する可能性があります。予期しないゼロがある方が良いです。たとえば、
# dd_rescue -A /dev/sdb2 /sdb2-image.img
これにより、一度に大量のデータを読み始め、エラーが発生し始めたときにのみチャンクが減ります。
編集：Micheal Johnsonが提案したように、質問に直接答えるためにconv=noerror,synconddまたは-Aoffを使用すると、dd_rescue画像はソースとまったく同じサイズになります。これは、すべての読み取りが同じサイズの書き込みを生成するためです。一部のバージョンはdd要求時にファイルの終わりに「エラー」を無視するため、デバイスがシャットダウンしても長時間実行されることがありますconv=noerror。私はLinuxがこれを行うとは思わないが、画像がソースファイルよりも大きく見える場合は知っておくべきことです。
答え2
イメージのサイズは、イメージを作成したパーティションのサイズと同じです。パーティションのサイズは言っていませんでしたが、全体のハードドライブ容量の半分であれば、ハードドライブのサイズに応じて、あなたが言ったサイズは無理ではありません。イメージを保管するパーティションには、少なくともイメージを作成したいパーティションと同じスペースが必要です。そうしないと、「デバイスに残りのスペースがありません」というエラーで操作が失敗します。また、sdc「壊れた」場合、画像をsdc1（画像ファイルパスでわかるように）保存するのは悪い考えかもしれません。 「壊れた」ということが何を意味するのかを明確にすることはできますか？
とにかく、スティーブボンズの答えはなぜそれほど時間がかかったのかを説明しますが、それはあなたが尋ねる質問ではありません。