我使用以下命令创建了我的一台虚拟服务器的磁盘映像(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
当我试图.img
在我自己的 unraid 机器上将 -file 作为 VM 运行时,我最终进入了 grub。所以我知道图像可能有问题。使用 ls 最重要的文件似乎在那里。
服务器有一个 15GB 的磁盘,但我没有意识到缺少一部分,因为它无论如何都被压缩了。生成的图像文件只有 4.3GB。
从那时起,我的 VPS 提供商删除了我的虚拟服务器。现在我意识到,存档不完整,因为它遇到了接收机器上的磁盘大小限制。
由于基本文件结构可用,而且我天真地认为前 4GB 包含我想要恢复系统的所有 VM。恕我直言,数据并不重要,但它似乎是值得学习和尝试的有用信息。我怀疑是分区信息有问题,系统由于某种原因找不到正确的引导路径。
执行时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 或类似工具增加这个大小吗?(我在具有 4TB 以上空间的 unraid 机器上运行它,但我怀疑这不是 @Bodo 的意思。)
此外,提取单个文件对我来说价值有限。很久以前,所有真正重要的东西都已备份,此映像的目的是能够启动我的软件在租用的虚拟服务器上运行的确切(或尽可能接近)环境。
Gparted(编辑2):
我刚刚查看了 gparted 路由:我收到此错误消息:
Invalid argument during seek for read on /dev/sdb
一个快速的谷歌搜索导致这个页面上的一个条目告诉我
分区表在磁盘的末尾
这就是分区信息丢失的原因。
由于 .img 文件太小,我无法使用“w”命令写入同一页面上提到的更改。我目前正在努力扩大这个文件。
巧合的是,我最近做了类似的事情(虽然是由于硬盘故障)。就我而言,ext4 恰好将有效负载存储在磁盘的开头,如下图所示(ext4 组使用情况超过组位置):
方式A:使用磁盘驱动器
方式B:放大原始图像文件
truncate -s 16 G image.img
(附加用零填充的空格)udisksctl loop-setup --file image.img
A 和 B 的共同点:
fsck.ext4 $device
用$device
作为驱动器或循环装置上的分区如果损坏足够小,系统可能仍可引导。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句