我使用以下命令创建了我的一台虚拟服务器的磁盘映像 (Ubuntu 18.04) 的 .gz 存档：
dd if=/dev/sdb | gzip -1 - | pv | ssh user@ip dd of=/home/user/sdb.gz
在解压存档时，我遇到了以下错误：
gzip: sdb.gz: unexpected end of file
当我尝试在我自己的 unraid 机器上作为虚拟机运行该.img文件时，我最终进入了 grub。所以我知道图像可能有问题。使用 ls 最重要的文件似乎就在那里。
服务器有一个 15GB 的磁盘，但我没有意识到有一部分丢失了，因为无论如何它都被压缩了。生成的图像文件只有 4.3GB。
从那时起，我的虚拟服务器已被我的 VPS 提供商删除。现在我意识到，存档不完整，因为它遇到了接收计算机上的磁盘大小限制。
由于基本文件结构可用，并且我天真地相信第一个 4GB 包含我想要恢复系统的所有虚拟机。恕我直言，这些数据并不重要，但它似乎是一些有用的东西，值得一试。我怀疑是分区信息有问题，系统由于某种原因找不到正确的启动路径。
我尝试了下面的步骤在本教程中从 Grub 引导和这个问题。
执行时linux /boot/vmlinuz-4.15.0-135-generic root=/dev/sda1，我收到错误：error: attempt to read or write outside of hd1。
对我来说正确的文件系统似乎是(hd1,1).
因此我 事先使用了set root=(hd1,1)
和 。set prefix=(hd1,1)/boot/grub
运行以下命令
insmod linux
insmod normal
normal
似乎什么也没做。
我需要执行哪些步骤才能使系统再次启动？我可以使用 ubuntu iso 来修复它吗？
附加信息（编辑）：
正如之前所说，原始 VPS 的大小为 15GB，我从损坏的 .gz 存档中提取的 .img 文件大小约为 4.3GB。我是否需要/是否能够使用 gparted 或类似工具来增加此大小？ （我在我的 unraid 机器上运行它，空间超过 4TB，但我怀疑这不是 @Bodo 的意思。）
此外，提取单个文件对我来说价值有限。所有真正重要的东西很久以前就已经备份了，这个映像的目的是能够启动我的软件在租用的虚拟服务器上运行的确切（或尽可能接近）的环境。
格帕特（编辑2）：
我刚刚查看了 gparted 路线：我收到了此错误消息：
Invalid argument during seek for read on /dev/sdb
快速谷歌搜索结果此页面上的一个条目这告诉我
分区表位于磁盘的末尾
这就是分区信息丢失的原因。
由于 .img 文件太小，我无法使用“w”命令来写入上述更改在同一页上。我目前正在努力扩大这个文件。
答案1
巧合的是，我最近做了类似的事情（尽管是由于硬盘故障）。就我而言，ext4 恰好将有效负载存储在磁盘的开头，如下图所示（ext4 组使用情况与组位置相比）：
方式A：使用磁盘驱动器
- 拥有足够大的磁盘来容纳整个映像
- 将损坏的映像添加到该磁盘上
方式B：放大原始图像文件
truncate -s 16 G image.img（附加用零填充的空格）- 安装图像
udisksctl loop-setup --file image.img
A 和 B 的共同点：
- 运行适当的文件系统检查器，例如
fsck.ext4 $device驱动$device器或循环设备上的分区 - 文件系统现在可以安装
如果损坏足够小，系统可能仍然可以启动。