コピーされたドライブよりも小さいDDイメージ
ライブUSBを介してサーバーのOSディスクのバックアップを取りました。コマンドの使用：
dd if=/dev/sda bs=512 count=(30 gb worth of sectors) conv=noerror,sync status=progress | gzip -c > /path/to/removable/media
コマンドはエラーなしで完了し、イメージが作成されました。 img.gzは16GBです
（サーバーのOSは最大15 GBのストレージを占有します）しかし、winrarで.gzを開くと、コンテンツはわずか2.21 GBであり、アーカイブは16GBであることがわかります。
これは、バックアッププロセスでエラーが発生したことを意味しますか、それともアーカイブがその中のイメージよりも大きくなるのは正常ですか？
ありがとう
バックアップ
まず、一般的なバックアップに関するアドバイスです。復元プロセスが機能することをテストおよび検証するまで、バックアップに依存することはできません。バックアップをテストする方法はいくつかあります。
- ハードウェアが手元にあり、それが重要なバックアップである場合は、物理ハードウェアへの完全な復元。
- 予備のハードウェアが不足している場合は、仮想マシンへの完全な復元。
- 起動可能なOSの復元を気にしない場合は、データを抽出し、正確性と完全性を検証します。
私は通常、WinZipで非圧縮サイズをチェックすることが特に役立つとは考えていません。ただし、取得した結果couldは、誤ったcountを指定したことを示しています。これにより、...
ddコマンドの問題
count=(30 gb worth of sectors)
これを見て最初に考えたのは、ドライブをバックアップするときにcountを指定してはいけないということです。特定のパーティションをバックアップする場合は、パーティションブロックデバイス（/dev/sdXNここで、Nは数値です）。それ以外の場合は、ddにドライブ全体を使用させる必要があります。 countを指定すると、データが破棄され、ファイルシステムが破損する可能性があるというリスクがあります（実際にはほぼ保証されます）。
コメントで、あなたは推論を提供しました：
ドライブは500GBで、最後の予備のHDDを友人に渡したので、500GBのイメージを収容できるファイルをダンプする場所がありませんでした。 OSは約15GBのスペースしかないため、安全のために30GBのセクターに相当するカウントを指定しました。
残念ながら、それはファイルシステムの仕組みではありません。ほとんどのファイルシステムは、すべてのデータがドライブの先頭に向かって保存されることを保証していません。
代替案
あなたがやりたいことをする他のいくつかの方法があります。
ファイル/データのみのアーカイブ
データのバックアップのみが必要で、起動可能なOSを復元できるかどうかをあまり気にしない場合は、tarコマンドを使用してのみファイルをバックアップできます。つまり、データはまだ残っていますが、OSを最初から再インストールし、データ（およびインストールされているアプリケーション）を手動で回復する必要があります。
- ファイルをアーカイブにコピーし、
tarをgzipにパイプします。
空き領域がゼロの圧縮バックアップ
これは多かれ少なかれあなたがすでに試みたことです。 gzipで正しい考えがあります。うまくいけば、未使用のスペース（verycompressible）を何も圧縮しません。コマンドからcountを削除するだけです。
残念ながら、削除されたファイルはまだディスク上に存在し、gzipには空として表示されないため、これは必ずしもうまくいくとは限りません。したがって、最初に 未使用スペースをクリアする にする必要があります。バックアッププロセスは次のようになります。
zerofreeなどで未使用のスペースをクリアしますdd（countなし）をgzipにパイプして、ドライブを圧縮イメージにコピーします
使用済みブロックのみをバックアップするツールを使用してください。 partclone
partcloneのように、使用済みのブロックを認識してバックアップするだけのスマートなツールがいくつかあります。 Arch wikiにはいくつかの例がありますgzipでの使用法について、 manual にはいくつかの例があります。これにより、パイプラインのddが効果的に置き換えられます。
データを復元するときは、同じツールを再度使用する必要があります。