次のコマンドを使用して、256GBのHDDからイメージを作成しました。
dd if=/dev/sda bs=4M | pv -s 256G | gzip > /mnt/mydrive/img.gz
後で、次のコマンドを使用して、別のコンピューター上の別の512GBHDDにイメージを復元しようとしました。
gzip -d /mnt/mydrive/img.gz | pv -s 256G | dd of=/dev/sda bs=4M
2番目のコマンドは、非常に長い時間ゼロバイトの進行を示し(秒を数えるだけですが、何も起こりません)、しばらくすると、エラーが表示されて失敗しますデバイスにスペースが残っていません。
問題は、画像ファイルを生の256GBファイルに解凍するときのgzipコマンドにありますxxx.img
そしてgzipを使用せずに復元すると、機能します。
dd if=/mnt/mydrive/xxx.img bs=4M | pv -s 256G | dd of=/dev/sda bs=4M
明らかに問題はgzip
コマンドにあります(gunzip
も試してみましたが、運がありません)。回避策として、煩わしい巨大な一時的な外付けドライブを使用してイメージを復元できます。圧縮された画像は、生の画像の約10%のサイズです。 gzip
が失敗する理由がわかりますか?
補足:問題はpv
またはdd
にありません。次のコマンドは、同じエラーメッセージで失敗します。
gzip -d /mnt/mydrive/img.gz > /dev/sda
次のコマンドは、意図したとおりに実行されていません。
gzip -d /mnt/mydrive/img.gz > /dev/sda
このコマンドは、ファイル/mnt/mydrive/img.gz
を解凍し、img.gz
の解凍されたコピーであるimg
というファイルを作成します。 stdoutを介して> /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が4GBを超えると失敗することがありましたが、4GBのファイルより大きくすることはできないというポップアップボックスが表示されます。 10ギガ以上の単一ファイルをgzipしている人は誰も知りません、あなたは256をやっています、私は単一ファイルにそれを決してしませんが、それは私の意見です。
dd
を使用し、ハードディスクイメージに対してそれを行う場合の問題は、/
パーティションが100%いっぱいではないことです。平均して10GBで、256GBの5%に相当するとします。この方法でdd
を使用すると、実際の情報の5%を含む256 GBのgzファイルがあり、残りの95%はディスク上のすべての空の[ランダム]値です。したがって、この理由から、この方法でdd
を使用することは望ましくありません。 dd
とディスク全体、特にTBディスク)に非常に長い時間がかかることは言うまでもありません。
1GB以下のブートまたはefiパーティションの場合、dd
はある程度許容されます。
私の意見では、dd
を使用してMBRディスクを使用し、最初の512 bytes[〜#〜] mbr [を保存/復元する必要があるのは唯一の場合です。 〜#〜]、それを単一のファイルとして保存します。
あなたのためにそれを行うソフトウェア以外の最良の解決策は、tar
を使用し、それが何であれブートローダーを理解することです。ただし、コンピューターを実行しているLinuxオペレーティングシステムを備えた2番目のディスクも必要です。次に、image
ファイルを保存するディスクをマウントします。これが原則です
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.
新しいディスクをイメージするには
_xfs
のような名前を付けて覚えておいてください。tar -cf
をtar -xf
に置き換えるだけです。bootプロセスは、Linux、efiとMBR、grubとgrub2とELILOの間で異なる可能性があるため、この時点で最もよくわかるのは、使用しているブートローダーとその方法reinstallそれだけで、新しいディスク用に再構成します。 LinuxディストリビューションのインストールDVDを起動し、ブートパーティションを修復させることで実行できる場合もありますが、これもLinuxディストリビューションによって異なります。
ここで、macriumやaomeiなどのクローン作成ソフトウェアを見つけるのが最適な場合があります。
Tarを介してこの手動クローン作成方法を実行する場合は、新しいディスクが古いディスクではないため、古いディスクへのすべての参照を新しいディスクに変更する必要があることに注意してください。特に[〜#〜] uuid [〜#〜] in /etc/fstab
ただし、名前でマウントを実行することでこれを軽減できますここで、fstabにはmount /dev/sda#
があり、新しいディスクが存在する唯一のディスクであり、sdaとして表示される場合に機能します。難しいのは、grub2または使用しているブートローダーを修正するための実行可能なプロセスを取得することです。 ELILOの時代は、見事で非常に簡単でした。elilo.confファイルの1行を変更するだけです。
だから私はエリロを連れ戻すと言います。 grubのgrand部分は必要ありません。