Перейти к содержанию
Форум русской поддержки продукции Synology

Active Backup for Buisness и восстановление на CentOS 8.5


Рекомендованные сообщения

Всем привет!

Имеется Active Backup for Buisness на DSM 7.0 DS218+, которым регулярно делаются бэкапы физического сервера под управлением CentOS 8.

Недавно обнаружил неприятный момент, который исправил и речь будет не о нем, но для информации оставлю тут. Когда зашел посмотреть на состояние копий, обнаружил, что в какой-то момент бэкапы делаться перестали. Попытка сделать копию вручную не удалась. Начал разбираться и выяснил, что после обновления программы, она перестала коннектиться с агентом на сервере. Пришлось обновлять агента для дальнейшего резервирования. Так что, при обновлении Active Backup for Buisness, нужно проверять и обновлять агентов на резервируемых серверах.

Теперь о проблеме.

Случилась на днях беда с системным диском на сервере CentOS, пришлось менять. На сервере LVM2 том на 4Тб, состоящий из 3 физических дисков - собственно системного SSD и 2-х дисков по 2Тб под файлопомойку. Резервируется системный диск полностью ("Системный том" в настройках программы).

Так вот, при восстановлении резервной копии LVM не поднялся. На системном диске обычная FS, не LVM2, файлы видны, сервер работает. Двух больших дисков не видно, поскольку том не восстановлен. Физически их видно, но примонтироваться они не могут из-за некорректного восстановления тома LVM2.

Кто-то сталкивался с восстановлением LVM из бэкапов? Можно ли поднять это аккуратно? В конфигурации дисков ничего не менялось, кроме замены самого системного диска. Разметка на нем не менялась.

Ссылка на сообщение
Поделиться на другие сайты

Не по теме, но общее замечание: при замене диска наверняка поменялся uuid. Если монтирование не по расположению, а по uuid, то надо лезть в конфиги.

Ссылка на сообщение
Поделиться на другие сайты

Он и поменялся.

[akiko@linux-srv ~]$ sudo vgcfgrestore -f /etc/lvm/archive/cl_linux-srv_00006-391774665.vg cl_linux-srv
  WARNING: Couldn't find device with uuid SON8PQ-W9tI-ISzR-UM2z-Ns2k-kon3-1Mcvhm.
  Consider using option --force to restore Volume Group cl_linux-srv with thin volumes.
  Restore failed.
[akiko@linux-srv ~]$ sudo vgcfgrestore -f /etc/lvm/archive/cl_linux-srv_00006-391774665.vg cl_linux-srv --force
[sudo] пароль для akiko: 
  WARNING: Couldn't find device with uuid SON8PQ-W9tI-ISzR-UM2z-Ns2k-kon3-1Mcvhm.
  WARNING: Forced restore of Volume Group cl_linux-srv with thin volumes.
  Cannot restore Volume Group cl_linux-srv with 1 PVs marked as missing.
  Restore failed.
[akiko@linux-srv ~]$ sudo pvdisplay
  --- Physical volume ---
  PV Name               /dev/sdb1
  VG Name               cl_linux-srv
  PV Size               <1,82 TiB / not usable 3,00 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              476931
  Free PE               476931
  Allocated PE          0
  PV UUID               EjH4kR-k34T-4XPP-UYuQ-ALZo-KbeC-PISfgO
   
  --- Physical volume ---
  PV Name               /dev/sdc2
  VG Name               cl_linux-srv
  PV Size               <1,82 TiB / not usable 1,00 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              476928
  Free PE               476928
  Allocated PE          0
  PV UUID               KDyZzU-3Bod-4VSi-v1kW-326o-bs7H-KFZBlc

1 PVs marked as missing - как раз /dev/sda3 на котором были /root и swap 

Просто, теперь пытаюсь понять, можно ли поднять том безболезненно, не похоронив окончательно данные на невидимых в томе дисках.

Если нельзя, то как можно эти данные вытащить, опять же, не закопав окончательно.

Так что, пока система работает, стараюсь лишних движений не делать, изучаю форумы. Коллекция видео и музыки не доступна, но тут можно и подождать.

Ну и кто доставал LVM тома из бэкапов Active Backup for Buisness, были ли проблемы?

Отредактировал Akikoz
Добавил инфу из консоли.
Ссылка на сообщение
Поделиться на другие сайты

1) Если есть 2 usb накопителя по 2+ ТБ, то делаем на них полную копию того, что сейчас находится на недоступных носителях:

mkdir /media/akiko/ваш_usb_диск/1/
sudo dd if=/dev/sdb of=/media/akiko/ваш_usb_диск/1/sdb.img status=progress

Аналогично, для sdc. Я бы еще и для sda сделал, на случай, если что-то совсем не так пойдет.

2) грузимся с любого live-cd носителя (чтобы sda3 был отмонтирован)

3)проверить, что sda3 у нас по прежнему sda3. Если нет - сделать соответствующие поправки.

sudo tune2fs /dev/sda3 -U SON8PQ-W9tI-ISzR-UM2z-Ns2k-kon3-1Mcvhm

4) Сразу же на sda3 проверить, как монтируется sda3 (/etc/fstab). Если по uuid - сделать правку.

5) Загрузиться в нормальном режиме

6) Повторить попытку восстановления lvm.

 

Если все пойдет совсем плохо, то благодаря п.1 Вы всегда сможете привести диски в состояние до вмешательства.

Ссылка на сообщение
Поделиться на другие сайты
52 минут назад, padla сказал:

У вас SON8PQ-W9tI-ISzR-UM2z-Ns2k-kon3-1Mcvhm - это uuid бывшего sda3?

Да, так и есть. Копию для него делать особого смысла не вижу, она на Синолоджи в бэкапах лежит, если что, до текущего состояния всегда восстановить смогу, уж хуже не будет.

Про tune2fs -U тоже была мысль, вроде как должно получиться, но вы правы, копии недоступных носителей сделать надо. Пока некуда, ищу жирный диск на время.

А почему именно USB? Если загружусь с livecd, на SATA подцеплю диск и на него положу 2 образа? Это принципиально?

Ссылка на сообщение
Поделиться на другие сайты
1 минуту назад, Akikoz сказал:

А почему именно USB? Если загружусь с livecd, на SATA подцеплю диск и на него положу 2 образа? Это принципиально?

Нет, конечно не принципиально. Просто по накатанной выдал. Перед тем, как лезу что-то чинить на чужом компе - делаю бекап. Как правило у меня под это именно usb диски идут (и дома под рукой, и на выезд с ними проще).

Ссылка на сообщение
Поделиться на другие сайты

Ок, спасибо, просто уточнил.

1 час назад, padla сказал:

4) Сразу же на sda3 проверить, как монтируется sda3 (/etc/fstab). Если по uuid - сделать правку.

Кстати... Сейчас он по uuid смонтирован, что там нужно будет в fstab после замены uuid посмотреть и поправить?

Сейчас fstab выглядит так. Невидимые точки монтирования закомментированы, чтобы система грузилась.

UUID=6c893e11-b9f4-4bfa-a263-f9c6fa944a0c /                       xfs     defaults        0 0
UUID=de89bd4a-3e35-406d-9ce4-948708892019 /boot                   ext4    defaults        1 2
UUID=628C-BA58          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
#/dev/mapper/cl_linux--srv-swap swap                    swap    defaults0 0
#UUID=465fdeb8-006a-4c39-9fb0-62e67bda20e1 /warez auto defaults,x-parent=DkN5am-7ei9-KPcv-x9Uu-2eM0-v51E-yKj5Pm 0 0
#/warez/warez /warez/nfs/warez none bind 0 0
#/warez/public /warez/nfs/public none bind 0 0
#/usr/restrict /warez/nfs/restrict none bind 0 0
akikoz-nas:/volume1/Warez /warez/nas/warez nfs defaults
akikoz-nas:/volume1/USBCopy /warez/nas/xchange nfs defaults

 

Ссылка на сообщение
Поделиться на другие сайты

Для раздела /dev/sda3 поменять uuid:

sudo cp /etc/fstab{,.bak}
sudo sed -i "s/6c893e11-b9f4-4bfa-a263-f9c6fa944a0c/SON8PQ-W9tI-ISzR-UM2z-Ns2k-kon3-1Mcvhm/" /etc/fstab

Либо можно отвязаться от uuid:

sudo sed -i "s|UUID=6c893e11-b9f4-4bfa-a263-f9c6fa944a0c|/dev/sda3|" /etc/fstab

 

Ссылка на сообщение
Поделиться на другие сайты

У Вас загрузочный и корневые разделы разные, возможно еще grub-у придется указать корень:

grub> linux /boot/vmlinuz-5.13.0-41-generic root=/dev/sda3

Маловероятно, что там привязка по uuid, но не исключено.

Ссылка на сообщение
Поделиться на другие сайты
1 час назад, padla сказал:

возможно еще grub-у придется указать корень:

Там все интересней. Поскольку раздел efi есть, загрузчик туда ставится. Надо заново инициализировать загрузчик efi. Уже сталкивался.

# efibootmgr -c -d /dev/sda -p 1 -L “CentOS” -l “\EFI\centos\grubx64.efi”

Ссылка на сообщение
Поделиться на другие сайты
2 часа назад, padla сказал:

Для раздела /dev/sda3 поменять uuid:

Думаю, не все так просто. Мне нужно создать на /dev/sda3 новый PV с нужным uuid.

Ссылка на сообщение
Поделиться на другие сайты
2 часа назад, Akikoz сказал:

Там все интересней. Поскольку раздел efi есть, загрузчик туда ставится. Надо заново инициализировать загрузчик efi. Уже сталкивался.

По идее не надо. efi загрузчик обеспечивает загрузку grub-а. grub обеспечивает загрузку ядра, начальной файловой системы и корня. Т.к. система у вас уже грузится, лезть в efi смысла нет. Если настройки и нужны, то на втором шаге. Но и это только в случае, если сейчас grub корень по uuid цепляет.

Проверить можно так:

grep "\slinux\s" /boot/grub/grub.cfg |grep root=UUID=

 

Ссылка на сообщение
Поделиться на другие сайты
2 часа назад, Akikoz сказал:

Думаю, не все так просто. Мне нужно создать на /dev/sda3 новый PV с нужным uuid.

Вот тут не подскажу. После выхода в релиз btrfs, смысла в lvm не видел, поэтому не изучал толком. Наверняка где-то что-то записывается в служебные поля, но в какой именно раздел - не знаю. Вот потому-то и предложил весь sda забекапить, на случай кривых рук.

Ссылка на сообщение
Поделиться на другие сайты

Ну, RHEL не включают в свои дистрибутивы btrfs, так что приходится пользоваться xfs + LVM :)

А про efi загрузчик я писал к тому, что он слетает при любых манипуляциях с диском. То есть, если у вас на диске есть efi раздел, после любых манипуляций с диском придется переинициализировать загрузку с него, сам он не загрузится от слова "совсем".

Сделал еще одну копию только /dev/sda3, потому что его потерять никак нельзя, там облако, а в облаке ВСЁ. Пока ищу куда скопировать 2х2 Тб.

Ссылка на сообщение
Поделиться на другие сайты
  • 2 месяца спустя...

Итак, после продолжительного перерыва, продолжение темы.

Что касается вышеизложенного. Куда сохранить 4Тб так и не нашел, в итоге, забил на это дело - за несколько дней практически всё перекачал заново, там почти ничего эксклюзивного не было. Теперь, систему оставил на отдельном разделе, вне тома LVM, во избежание повторения ситуации. На LVM теперь только склад файлов. Казалось бы, на этом всё, но история получила продолжение.

Недавно заметил, что сервер снова перестал бэкапиться. Было подозрение на 3 момента: обновление самого ABB, обновление сертификата, обновление ядра системы. Это то, что менялось в промежутке перед прекращением работы ABB. С полной уверенностью не могу сказать, что именно стало причиной, но склоняюсь к тому, что причина - обновление ядра. Поясню почему.

 Поскольку такое уже было, бэкапы отваливались, восстановление работы лечилось переустановкой агента на сервере. Так же сделал и в этот раз. Кстати, о том, что свежеустановленный агент не спрашивая отправляет сервер в перезагрузку, можно было и предупредить, но это отдельная песня. Агента переустановил, но ABB так и не получил доступа к серверу, задача бэкапа вываливается с ошибкой:
image.png.7061418854ce1819d7e18db002452906.png

Кроме того, получил ошибку службы systemd-modules-load, которая не находит "synosnap":

image.png.4a7b1624fc416b623dbb05008a49cf20.png

Пробовал удалять и ставить агента и драйвер заново. После удаления остаются "хвосты", systemd-modules-load так же не стартует, приходится подчищать руками. В итоге, всё вроде бы устанавливается, ошибок нет, но ABB так и не получает доступа к серверу, Service Status: Idle - Failed, бэкапы не делаются.

[xxxxxx@linux-srv Downloads]$ sudo ./install.run 
[sudo] пароль для xxxxxx: 
Verifying archive integrity...  100%   MD5 checksums are OK. All good.
Uncompressing Active Backup for Business Agent  100%  
 * kernel-devel-4.18.0-408.el8.x86_64 has already installed
 * make has already installed
 * libaio has already installed
 * epel-release has already installed
 * dkms has already installed
 * start installing snapshot driver and agent service
 * installed snapshot driver is newer, no need to install
 * installed agent service is newer, no need to install
 * The installation is complete. You might enter "abb-cli -c" to connect to Synology NAS and back up the Linux device. To learn more commands about Active Backup for Business Linux agent, please type "abb-cli -h".

[xxxxxx@linux-srv Downloads]$ sudo abb-cli -c
Already connected

[xxxxxx@linux-srv ~]$ sudo abb-cli -s
[sudo] пароль для xxxxxx: 
Server address: 111.222.333.444                     Username: xxxxxx
Last backup time: 2022-07-17 02:07               Next backup time: 2022-08-07 02:00
Service Status: Idle - Failed

Restore portal: https://xxxxxxxxxx/?launchApp=SYNO.SDS.ActiveBackupPortal.Application&launchParam=device_id%3D6

For detailed activity logs, please refer to the system logs. Depending on the operating system of your Linux device, you can find the logs in var/log/message, var/log/syslog, or by entering the command journalctl.
Retrieved service status successfully

[xxxxxx@linux-srv ~]$ sudo systemctl --failed --all
[sudo] пароль для xxxxxx: 
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION                                                                                                                                                                                                                          
● systemd-modules-load.service loaded failed failed Load Kernel Modules                                                                                                                                                                                                                  

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.

[xxxxxx@linux-srv ~]$ journalctl -b -u systemd-modules-load.service
-- Logs begin at Sun 2022-07-31 18:58:17 MSK, end at Sun 2022-07-31 19:12:19 MSK. --
июл 31 18:58:18 linux-srv systemd[1]: systemd-modules-load.service: Succeeded.
июл 31 18:58:18 linux-srv systemd[1]: Stopped Load Kernel Modules.
июл 31 18:58:19 linux-srv systemd-modules-load[689]: Module 'msr' is builtin
июл 31 18:58:19 linux-srv systemd-modules-load[689]: Failed to find module 'synosnap'
июл 31 18:58:19 linux-srv systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
июл 31 18:58:19 linux-srv systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
июл 31 18:58:19 linux-srv systemd[1]: Failed to start Load Kernel Modules.

Кстати, видел в соседней теме, после обновления ABB у народа тоже проблемы.

Ссылка на сообщение
Поделиться на другие сайты

У меня с такой же ошибкой завершается бекап одного из ПК на Win10. При этом 23 машины и 4 сервера нормально бекапятся по расписанию и вручную. А два ПК вообще не могу добавить: в логах добавлены, в списке отсутствуют. Что только не делал с клиентом, бесполезно. Пока плюнул: ищу инфу, читаю...

Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете опубликовать сообщение сейчас, а зарегистрироваться позже. Если у вас есть аккаунт, войдите в него для написания от своего имени.

Гость
Ответить в этой теме...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

Загрузка...
×
×
  • Создать...