☰

使用 gzip 恢复 HDD 映像会引发错误“设备上没有剩余空间”

tag-icon • tag-icon dd gzip pv
使用 gzip 恢复 HDD 映像会引发错误“设备上没有剩余空间”

我使用以下命令从 256GB HDD 创建了一个映像：

dd if=/dev/sda bs=4M | pv -s 256G | gzip > /mnt/mydrive/img.gz

后来我尝试使用以下命令将映像恢复到另一台计算机上的另一个 512GB HDD：

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

第二个命令显示很长时间的零字节进度（仅计算秒数，但没有任何反应），一段时间后它失败并显示错误告诉我设备上没有剩余空间。

问题出在 gzip 命令中，当我将图像文件解压为原始 256GB 文件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

答案1

以下命令并不完全符合您的预期

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

该命令解压缩文件/mnt/mydrive/img.gz并创建一个名为 的文件，img该文件是img.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

答案2

我不知道为什么 gzip 失败，可能与 32 位有关。我在 Windows 上安装了一个 [旧] 版本的 winzip，在处理任何超过 4GB 的文件时都会失败，但它会弹出一个框，提示不能处理大于 4GB 的文件。我不知道有谁对任何单个文件进行 gzip 压缩超过 10 次，而你正在做 256 个，我永远不会对单个文件这样做，但这是我的观点。

使用dd硬盘映像并执行此操作的问题是您的/分区未 100% 已满。假设它平均有 10GB，相当于 256GB 的 5%。当您dd以这种方式使用时，您将拥有一个 256 GB 的 gz 文件，其中包含 5% 的真实信息，其余 95% 是磁盘上的所有空[随机]值。因此，dd出于这个原因，您不想以这种方式使用。更不用说dd整个磁盘，尤其是 TB 磁盘的时间长得离谱。

对于 1GB 或更小的 boot 或 efi 分区，dd在某种程度上是可以接受的。

在我看来，您应该使用的唯一一次dd是在 MBR 磁盘上保存/恢复第一个 512字节的膜生物反应器，将其保存为单个文件。

除了为您执行此操作的软件之外，最好的解决方案是使用tar和理解引导加载程序，无论它是什么。但您还需要第二个磁盘，其中运行计算机的 Linux 操作系统，然后安装要保存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.

为新磁盘创建映像

  • 挂载新磁盘
  • 将分区格式化为您喜欢的任何大小，大小必须大于相应的 tar 文件，这应该是显而易见的
  • **要求*是如果 root.tar 位于 XFS 文件系统上，则必须将其解压到 XFS 文件系统上；您无法决定将新磁盘分区为其他类型，例如 EXT4 或 BTRFS，并解压缩该 root.tar 文件（该文件属于该 Linux 操作系统的 xfs 文件系统）。我试过了，无法启动。因此，请将您的根目录和启动 .tar 文件命名_xfs为您可以记住的名称。
  • 只需将其替换tar -cf为tar -xf即可恢复方法
  • 现在剩下的就是独立于操作系统的引导机制。

因为启动linux、efi 与 MBR、grub、grub2 与 ELILO 之间的过程可能有所不同，此时我可以告诉您的是，您需要了解您正在使用的引导加载程序以及如何重新安装仅此而已，然后为新磁盘重新配置它。 有时可以通过启动 linux 发行版安装 DVD 并让它修复启动分区来完成但这又取决于 Linux 发行版。

在这里可能最好找到克隆软件，例如 macrium 或 aomei。

如果您决定通过 tar 执行此手动克隆方法，请意识到新磁盘不是旧磁盘，因此对旧磁盘的所有引用都需要更改为新磁盘。特别是通用唯一标识符但是/etc/fstab你可以通过安装来缓解这种情况按名字其中 fstab 具有mount /dev/sda#并且只要新磁盘是唯一存在的磁盘并且显示为 sda，该功能就可以工作。困难的部分是找到一个可行的过程来修复 grub2 或您正在使用的任何引导加载程序。在 ELILO 时代，这非常辉煌且非常简单，只需修改 elilo.conf 文件中的一行即可。

这就是为什么我说带回 ELILO。没有人需要盛大grub 的一部分。

相关内容