У сервера openmediavault умер ssd диск, и я заменил его на новый (другой марки, той же емкости). Теперь я хочу восстановить мою последнюю резервную копию, сделанную с помощью fsarchiver через плагин omv backup, и я следую этому руководству. Выполнив первые 13 шагов, я застрял на последних двух, где делаются критические вещи.
Это были разделы на моем новом диске 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
Но теперь я этого не вижу.
Edit: размеры различных резервных файлов:
-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
переустановил OMV снова в режиме UEFI, чтобы восстановить таблицу разделов, и поскольку новый ssd имеет ту же емкость, что и старый, я пропустил часть восстановления grub и напрямую восстановил резервную копию файловой системы с помощью fsarchive.
MBR находится в секторе 0, "основной" GPT занимает сектора 1-33, а "резервный" GPT находится в конце диска).
Диски GPT обычно используются с прошивкой UEFI, а процесс загрузки EFI не использует "загрузочный сектор" - это нормально, когда защитный MBR сопровождается абсолютно пустой областью загрузочного кода. (Загрузчик для систем EFI хранится в виде обычного файла в обычном разделе).
Есть два варианта:
Поискать другой файл, который может содержать правильную таблицу разделов.
после восстановления таблицы разделов с помощью dd
, вам может понадобиться явно указать ядру на повторное сканирование - иначе узлы /dev не появятся сами по себе. Это можно сделать с помощью partx -u
, или partprobe
, или запустив fdisk
и попросив его 'w'rite найденные разделы).
перестроить таблицу разделов с нуля, создав разделы, используя номера "начального" и "конечного" секторов, которые удобно иметь в старом выводе 'fdisk'.
(Вам не нужно вручную создавать "расширенный" раздел, просто p1 как "первичный" и p5 как "логический").
У меня было то же самое после восстановления OMV6 с помощью fsarchiver на Raspberry OS. Восстановленная система всегда загружалась в режиме только для чтения. Однако перемонтирование в режиме r/w работало. Проблема (в моем случае) была довольно простой: /etc/fstab ссылается на файловые системы по partuuid вместо /dev/mmcblk0p****.
Что я сделал:
Я полагаю, это означает, что partuuid после восстановления отличается от того, который был в резервной копии файла /etc/fstab.