ddコンピュータのハードドライブをバックアップするために使用してみましたが、かなり混乱した結果に遭遇しました。複数のソースで確認しました（例：http://www.backuphowto.info/linux-backup-hard-disk-clone-dd、http://debianhelp.co.uk/ddcommand.htm) には次のような内容が含まれています。
dd if=/dev/sda of=~/backup.img
1) 非常に混乱していない限り、これはディスク全体をディスク上のファイルにバックアップしようとするのではないでしょうか?
私はこの方法を試してみましたが、まずスペースを節約するために出力を圧縮しました。圧縮されたファイルが空きデータをすべてコピーしようとして大量のスペースを占有するのを防ぐために、zerofreeディスクの未使用スペースすべてに 0 を書き込んでいました。私のディスクの合計容量は約 320 GB で、そのうち約 100 GB が使用されており、約 220 GB が空きです。
次のコマンドを使用しようとしました:
dd if=/dev/sda | gzip -c > ~/image.img.gz
バックアップ ファイルのサイズは、バックアップを終了する前に約 160 GB に達しました (外部ディスクにバックアップする方法を見つけ出すことが目的でした。このタスクはその後成功しました)。
2) バックアップがなぜそんなに多くのスペースを占有するのでしょうか?dd書き込み先のファイルを認識し、そのファイルもバックアップしようとするからでしょうか? それとも、zerofree適切に使用できなかったために、そのような事態を防ごうとしたにもかかわらず、大量のランダムなジャンク データがバックアップされてしまったのでしょうか?
答え1
変更中のハードドライブを正確に複製することはできません。
私が非常に混乱していない限り、これはディスク全体をディスク上のファイルにバックアップしようとするのではないでしょうか?
はい、試行します。ddコマンドはブロックを (ドライブから) 読み取り、ブロックを圧縮し、ブロックを (そのドライブ上のファイルに) 書き込み、次のブロックに進みます。イメージには、部分的に書き込まれたファイルbackup.imgと、そのファイルへの部分的に書き込まれたファイルシステム ポインターが含まれます。
注:詳細はここでは関係ないためdd、と 間のパイプ バッファリングを大幅に簡略化しました。gzip
バックアップはなぜそんなに多くのスペースを占有するのでしょうか?
原因としては、部分的に書き込まれたファイルをコピーしようとしていることが考えられますbackup.img。その他の要因としては、使用しているファイルシステムのファイルシステム構造に関する高度な知識が必要です。