gzipを使用してHDDイメージを復元すると、「デバイスに残りのスペースがありません」というエラーが発生します。

次のコマンドは、期待したものとまったく一致しません。

gzip -d /mnt/mydrive/img.gz > /dev/sda

このコマンドはファイルを解凍し、という/mnt/mydrive/img.gzファイルを生成します。これは標準出力には何も送信されないため、役に立ちません。imgimg.gz> /dev/sda/dev/sda

---

これがあなたがしなければならないことです。出力をstdoutに送信します（を使用して-c）：

gunzip -c /mnt/mydrive/img.gz > /dev/sda

または

gunzip -c /mnt/mydrive/img.gz | pv -s 256G | dd of=/dev/sda bs=4M

私はいません。知るgzipが失敗する理由は32ビットに関連している可能性があります。 Windowsにインストールされている以前のバージョンのwinzipが4 GBを超えるファイルを処理すると失敗しますが、4 GBを超えるファイルを処理できないというポップアップボックスが表示されます。私は単一のファイルを10回以上gzipで圧縮した人を知りません。あなたは256を実行しています。私は単一のファイルにそのようなことをしないでしょう。しかし、それが私の意見です。

ddハードディスクイメージを使用する際の問題は、/パーティションが100％いっぱいになっていないことです。平均して10GBがあり、これは256GBの5％に相当します。このように使用すると、dd実際の情報の5％を含む256GBのgzファイルが生成され、残りの95％はすべてディスク上の空の[ランダム]値です。したがって、ddこのように使用したくありません。ddディスク全体、特にテラバイトディスクの場合、時間が非常に長くかかることは言うまでもありません。

1GB以下のブートまたはefiパーティションの場合、ddこれはある程度許可されています。

私の考えでは、この機能を使用する唯一の時間は、ddMBRディスクの最初の512を保存/復元することです。バイト~の膜バイオリアクター、単一のファイルとして保存します。

これを行うソフトウェアを除いて、最善の解決策は、tarブートローダが何であれ使用して理解することです。ただし、コンピュータ上のLinuxオペレーティングシステムを実行してからファイルを保存するディスクをimageマウントするための2番目のディスクも必要です。これが原則です

for example let's say the disk to be imaged is partitioned like this,
which is about the minimum required and currently done in RHEL/CentOS 7

/dev/sdc1      /boot         1gb      XFS
/dev/sdc2      /boot/efi   100mb      EFI
/dev/sdc3      /            99tb      XFS

# mount disk to have an image of it saved, let's say it shows up as `/dev/sdc`
# going to save image files of each partition under root folder
# assuming there is enough space to do so there

mkdir /sdc1
mount   /dev/sdc1   /sdc1
cd /sdc1

tar -cf /root/boot.tar *

# boot partition is 1gb total size, but only has 300mb on it so you only have to manage a 300gb boot.tar file

cd /
umount /sdc1
mkdir /sdc2
mount   /dev/sdc2   /sdc2
cd /sdc2

tar -cf /root/efi.tar *

# efi partition is 100mb, but only has 5mb on it, so only a 5mb efi.tar file

cd /
umount /sdc2
mkdir /sdc3
mount   /dev/sdc3   /sdc3
cd /sdc3

tar -cf /root/root.tar   *

# root partition was however big, but only has N gb of actual file system data so you end up with an N gb  root.tar file to have to worry about.

cd /
umount /sdc3
disconnect that disk from computer
# move or rename the boot.tar, efi.tar, and root.tar files as necessary.

新しいディスクのイメージの作成

• 新しいディスクマウント
• パーティションを希望のサイズにフォーマットしてください。サイズは対応するtarファイルより大きくなければなりません。これは明らかです。
• **要件*は、root.tarがXFSファイルシステムにある場合は、XFSファイルシステムに解凍する必要があることです。新しいディスクを EXT4 や BTRFS などの他のタイプに分割し、ルートを解凍することを決定することはできません。 tarファイル（このファイルはこのLinuxオペレーティングシステムのxfsファイルシステムに属します）。試してみましたが、開始できません。そのため、ルートディレクトリと起動する.tarファイルの名前を覚えて_xfsおいてください。
• この方法は、単に次のようtar -cfに交換することでtar -xf復元できます。
• 今残っているのは、オペレーティングシステムとは独立した起動メカニズムだけです。

なぜなら始めるプロセスは、linux、efi vs MBR、grub、grub2 vs ELILO 間で異なる場合があります。この時点で私が言うことができるのは、どのブートローダを使用しているのか、どのように使用するのかを理解する必要があるということです。再インストールそれはすべてです。次に、新しいディスクに合わせて再構成します。 LinuxディストリビューションのインストールDVDを起動してブートパーティションを回復すると、これを行うことができます。しかし、これは再びLinuxディストリビューションによって異なります。

おそらく、macriumやaomeiなどのレプリケーションソフトウェアを見つけるのが最善の場所でしょう。

tarでこの手動レプリケーション方法を実行することを決定した場合、新しいディスクは古いディスクではないため、古いディスクへのすべての参照を新しいディスクに変更する必要があります。特に普遍的に一意の識別子ただし、/etc/fstab以下をインストールするとこの問題を軽減できます。名前でfstab には、mount /dev/sda#新しいディスクが 1 つだけ sda として表示される限り、この機能は機能します。難しい部分は、grub2または使用中のブートローダを変更するための実行可能なプロセスを見つけることです。 ELILO時代には、elilo.confファイルで1行だけ変更すると、この作業は素晴らしく簡単でした。

だから私は再びELILOをインポートするように言います。誰もいらない素晴らしいグラップの一部。