Таблицу разделов и резервную копию fsarchiver с мертвого диска на новый

Таблицу разделов и резервную копию fsarchiver с мертвого диска на новый
Таблицу разделов и резервную копию fsarchiver с мертвого диска на новый - anishlk @ Unsplash

У сервера 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.

Похоже, что файл

grubparts взят не с того диска. Ваш "старый" список разделов показывает обычную таблицу разделов формата MBR, но то, что вы восстановили, похоже на "защитную MBR", которая обычно встречается на дисках с GPT-разделами - у нее есть специальный раздел типа 0xEE, который обычно указывает: "Вам не следует искать здесь, вместо этого вам следует посмотреть на GPT в секторе 1".

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****.

Что я сделал:

  • Перемонтировать root как r/w
  • PARTUUID=xyz с /dev/mmcblk0p*** в /etc/fstab
  • Перезагрузите

Я полагаю, это означает, что partuuid после восстановления отличается от того, который был в резервной копии файла /etc/fstab.


NevaDev, 1 февраля 2023 г., 12:35