我的 openmediavault 服务器的 ssd 磁盘坏了，我用一个新的（不同的品牌，相同的容量）替换了它。现在我想通过 omv 备份插件恢复我使用 fsarchiver 进行的最后一次备份，并且我正在遵循本指南。在完成前 13 个步骤之后，我被困在最后 2 个步骤中，关键的事情已经完成。
这些是尝试恢复之前我的新 ssd nvme 磁盘上的分区（我在上面安装了 OMV）：
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 2048 486395903 486393856 231.9G 83 Linux
/dev/nvme0n1p2 486397950 488396799 1998850 976M 5 Extended
/dev/nvme0n1p5 486397952 488396799 1998848 976M 82 Linux swap / Solaris
在我运行“恢复 grub 和分区表”步骤之后：
dd if=/mnt/array/Backup/omvbackup/backup-omv-30-ago-2021_03-00-01.grubparts of=/dev/nvme0n1
现在看起来像这样：
Device Boot Start End Sectors Size Id Type
/dev/nvme0n1p1 1 488397167 488397167 232.9G ee GPT
当我尝试恢复主分区时：
fsarchiver restfs backup-omv-30-ago-2021_03-00-01.fsa id=0,dest=/dev/nvme0n1p1
我收到以下错误：
oper_restore.c#152,convert_argv_to_strdicos(): "/dev/nvme0n1p1" is not a valid block device
所以我想我弄乱了分区表。也许 grubparts 没有写入 /dev/nvme0n1 而是写入其他地方？在尝试恢复分区表之前，我可以看到安装了 GRUB：
dd bs=512 count=1 if=/dev/nvme0n1 2>/dev/null | strings
但我再也看不到了。
编辑：不同备份文件的大小：
-rw-r--r-- 1 root users 818 *.blkid
-rw-r--r-- 1 root users 590 *.fdisk
-rw-r--r-- 1 root users 5226895118 *.fsa
-rw-r--r-- 1 root users 446 *.grub
-rw-r--r-- 1 root users 1408 *.grubparts
-rw-r--r-- 1 root users 1035 *.packages
看起来 .grubparts 文件来自错误的磁盘。您的“旧”分区列表显示了一个正常的 MBR 格式的分区表，但是您恢复的看起来像通常在 GPT 分区磁盘上找到的“保护性 MBR”——它具有类型 0xEE 的特殊分区，通常表示“你应该不要看这里，你应该看第 1 区的 GPT”。
（MBR 位于扇区 0，而“主”GPT 占用扇区 1-33，“备份”GPT 位于磁盘末尾。）
此外，GPT 磁盘通常与 UEFI 固件一起使用，并且 EFI 引导过程不使用“引导扇区”——保护性 MBR 伴随着完全空白的引导代码区域是正常的。（EFI 系统的引导加载程序作为常规文件存储在常规分区中。）
有两种选择：
寻找另一个可能具有正确分区表的文件。
（此外，在使用 恢复分区表后
dd，您可能需要明确告诉内核重新扫描它 - 否则 /dev 节点将不会自行出现。这可以使用partx -u、 或partprobe或通过运行fdisk并要求它来完成'写它找到的分区。）通过使用旧的“fdisk”输出中方便的“开始”和“结束”扇区号创建分区，从头开始手动重建分区表。
（您不需要手动创建“扩展”分区，只需将 p1 作为“主”，将 p5 作为“逻辑”。）
我在UEFI模式下重新安装了OMV以恢复分区表，并且由于新ssd与旧ssd容量相同，因此我跳过了grub恢复部分，直接使用fsarchive恢复了文件系统备份。
在 Raspberry OS 上对 OMV6 进行 fsarchiver 还原后，我也遇到了同样的情况。恢复的系统始终以只读模式启动。以 r/w 模式重新安装虽然有效。问题（就我而言）实际上非常简单：/etc/fstab 通过 partuuid 而不是 /dev/mmcblk0p**** 引用文件系统。
我做了什么：
我想这意味着还原后的 partuuid 与备份文件 /etc/fstab 中的 partuuid 不同。