31. Накатывание на хост чужого снимка с помощью LVM и BorgBackup
2022-04-04
Подготовительные мероприятия
В минимальной комплектации необходимо восстановить системные разделы /
, /boot
, /var
. В максимальной комплектации потребуется восстановить ранее забэкапированные /data
и прочее.
В любом случае, для распаковки этих данных потребуется достаточное незанятое место на Volume Group’ах, несущих восстанавливаемые Logical Volume’ы. В простейшем случае для этого необходимо добавить к машине дополнительный диск вместимостью перекрывающим объём восстанавливаемых данных.
Добавление пространства в Volume Group
Если требуется восстанавливать только один VG, то разбивать дополнительный диск на разделы не требуется. Достаточно будет добавить в VG весь новый диск командой vgextend /dev/vg /dev/sdb
.
В противном случае, когда восстанавливаемые тома находятся на разных VG, потребуется разбивка дополнительного диска на отдельные разделы и добавление этих новых PV в свои VG.
Процесс восстановления
Отключение работающих демонов
В дополнение к остановке главных сервисов, работающих на машине, останавливаем второстепенные, которые могут вызвать переполнение на LV места выделенного под снэпшоты. Пример остановки дополнительных сервисов:
systemctl stop postfix
systemctl stop rsyslog
service auditd stop
Создание LVM snapshot
Помним, что в Volume Group должно быть достаточно свободного места для размещения данных из бэкапов. В отличие от процесса создания бэкапа, в этом случае нужно много места, чтобы уместить сюда весь бэкап.
lvcreate -L 6G -s -n snap_root /dev/vg/root
lvcreate -L 6G -s -n snap_var /dev/vg/var
Проверяем детали восстанавливаемого снимка
Выбор восстанавливаемого снимка
Устанавливаем переменные, чтобы не вводить параметры дважды:
export BORG_RSH="ssh -i ~/.ssh/borg1"
export BORG_REPO="borg@192.168.50.10:home-ipa"
Выбираем нужный архив из списка. Пример списка:
borg list
...
full_img211202_2022-03-11T10:54:32 Fri, 2022-03-11 10:54:35 [f681b040b6f7579e424cc328207e44aac50205ffaaa6d6923417ec598807b4b4]
Подключение восстанавливаемого снимка
borg mount ::full_img211202_2022-03-11T10:54:32 /mnt
Проверка /etc/fstab
Отмечаем имена подключаемых разделов и тип файловой системы (ext4 или xfs) у восстанавливаемого снимка:
cat /mnt/etc/fstab
Проверяем файловые снимки на хосте:
df -T
Отмонтируем снимок
borg umount /mnt
Монтирование снэпшотов + директорию /boot
Если типы файловых систем совпадают
При монтировании xfs используем опцию nouuid
:
# Mounting root on /mnt/sysroot
LV='/dev/vg/snap_root'
SYSROOT='/mnt/sysroot'
mkdir -p ${SYSROOT}
FSTYPE=$(df -T ${LV/snap_/} | egrep "ext4|xfs" | awk '{print $2}')
if [[ ${FSTYPE} = "xfs" ]]; then
mount -o nouuid ${LV} ${SYSROOT}
elif [[ ${FSTYPE} = "ext4" ]]; then
mount ${LV} ${SYSROOT}
fi
# Mounting /var on /mnt/sysroot/var
LV='/dev/vg/snap_var'
FSTYPE=$(df -T ${LV/snap_/} | egrep "ext4|xfs" | awk '{print $2}')
if [[ ${FSTYPE} = "xfs" ]]; then
mount -o nouuid ${LV} ${SYSROOT}/var
elif [[ ${FSTYPE} = "ext4" ]]; then
mount ${LV} ${SYSROOT}/var
fi
# Mounting /boot on /mnt/sysroot/boot
mount -o bind /boot ${SYSROOT}/boot
Если типы файловых систем различны
Форматируем разделы. Например, если восстанавливаемый снимок создан на машине с ’ext4':
# /dev/sda1 --> /boot
umount /boot
mkfs.ext4 /dev/sda1
# /dev/vg/root --> /
mkfs.ext4 /dev/vg/snap_root
# /dev/vg/var --> /var
mkfs.ext4 /dev/vg/snap_var
Монтируем вручную отформатированные разделы к каталогу /mnt
:
mount /dev/vg/snap_root ${SYSROOT}
mkdir ${SYSROOT}/{boot,var}
mount /dev/sda1 ${SYSROOT}/boot
mount /dev/vg/snap_var ${SYSROOT}/var
Проверка монтирования
mount | grep '/mnt'
Пример вывода:
/dev/mapper/vg-snap_root on /mnt/sysroot type ext4 (rw,relatime,seclabel)
/dev/mapper/vg-snap_var on /mnt/sysroot/var type ext4 (rw,relatime,seclabel)
/dev/sda1 on /mnt/sysroot/boot type ext4 (rw,relatime,seclabel)
Удаление содержимого снэпшотов и /boot
Если разделы были отформатированы на одном из предыдущих пунктов, то удаление содержимого разделов можно пропустить.
Иначе удаляем всё содержимое снэпшотов и каталога /boot
с проверкой:
rm -ri ${SYSROOT}/*
tree ${SYSROOT}
Результат:
/mnt/sysroot
└── [4.0K] boot
└── [4.0K] var
2 directory, 0 files
Восстановление бэкапа в пространство снэпшотов и /boot
Переходим в корень и восстанавливаем архив full_img211202_2022-03-11T10:54:32
, который заполнит файлами готовый для приёма каталог /mnt/sysroot
:
cd /
borg extract --list --progress --numeric-owner \
::full_img211202_2022-03-11T12:53:10
Исправление загрузки
chroot для исправления загрузки
mount -t proc /proc ${SYSROOT}/proc/
mount -t sysfs /sys ${SYSROOT}/sys/
mount --bind /dev ${SYSROOT}/dev/
mount --bind /run ${SYSROOT}/run
chroot ${SYSROOT}
Обновление GRUB
В некоторых случаях, например при восстановлении снимка с другой операционной системой, потребуется обновить GRUB.
Общая схема обновления GRUB такая:
- Генерируем новый
/boot/grub/grub.cfg
. Это необходимо сделать, так как восстанавливаются только файлы, но не UUID’ы разделов на диске. - Так как песочница, в которой производилась генерация
grub.cfg
, находится на LV с именамиsnap_root
иsnap_var
, то исправляем в сгенерированном/boot/grub/grub.cfg
названия разделов. - Переустанавливаем GRUB в MBR (плюс ещё несколько секторов).
if [ -e /usr/sbin/grub-mkconfig ]; then grub-mkconfig -o /boot/grub/grub.cfg sed -i 's/vg-snap_root/vg-root/g' /boot/grub/grub.cfg grub-install /dev/sda elif [ -e /usr/sbin/grub2-mkconfig ]; then grub2-mkconfig -o /boot/grub2/grub.cfg sed -i 's/vg-snap_root/vg-root/g' /boot/grub2/grub.cfg grub2-install /dev/sda else echo "Houston, we have a problem." fi
Эталонный вывод после grub-install
:
Installing for i386-pc platform.
Installation finished. No error reported.
⚠️ Если произошли ошибки, то машина с большой вероятностью загрузится в ‘grub recovery’-режиме.
Исправляем /etc/fstab
⚠️ Напомню, что файл
/etc/fstab
обязательно должен заканчиваться ‘новой строкой’, иначе ОС не сможет загрузиться.
Приводим /etc/fstab
в актуальное состояние, так как в нём указаны устаревшие сведения, оставшиеся от машины донора.
Необходимо помнить, что в /etc/fstab
могут быть просто не указаны некоторые разделы. Например, восстанавливаемый снимок машины, на которой отсутствовал LV-том /dev/vg/var
(то есть каталог /var
находится в LV-томе /dev/vg/root
), не будет иметь соответствующей строки в /etc/fstab
. Если такой снимок будет развёрнут с песочнице с подключённым /dev/vg/var
к /var
, то потребуется вручную добавить в /etc/fstab
строку /dev/vg/var /var defaults 1 2
.
⚠️ Рекомендуется указывать в
/etc/fstab
UUID раздела/boot
, так как на машинах AltLinux 10 с двумя дисками я наблюдал рокировки между/dev/sda
и/dev/sdb
после перезагрузок машины. На машинах с другими ОС такого пока не наблюдалось.
Естественно, если восстанавливаемый снимок создавался на этой же машине, то этот пункт можно пропустить.
Исправляем имя хоста
Проверяем/исправляем содержимое файлов /etc/hostname
и /etc/hosts
.
Обновление initramfs
При восстановлении снимка с другой операционной системой или при различии в версиях Linux-ядра, возможно потребуется указывать версию ядра, для которого генерируется initramfs.
Версию текущего ядра можно узнать через команду uname -r
.
Версии Linux-ядер в восстанавливаемом снимке видны в каталоге /boot
.
CentOS 7, RedOS 7.2
dracut -f -v
dracut -f -v /boot/initramfs-4.19.204-2.el7.x86_64.img 4.19.204-2.el7.x86_64
AltLinux 10
make-initrd
или при необходимости указания версии ядра:
make-initrd --kernel='5.10.82-std-def-alt1'
Исправляем сетевые настройки
Предполагается, что системный администратор умеет исправить сетевые настройки должным образом.
Генерируем новые sshd-ключи
Требуется в случае, например, массового восстановления снимка одной машины на некоторое количество машин.
#DIR="/etc/openssh" # AltLinux
DIR="/etc/ssh"
rm -f ${DIR}/ssh_host_*
ssh-keygen -t rsa -b 4096 -f ${DIR}/ssh_host_rsa_key -N ""
ssh-keygen -t ed25519 -a 100 -f ${DIR}/ssh_host_ed25519_key -N ""
systemctl restart sshd
Предполагается, что ключи DSA и ECDSA закомментированы в
/etc/ssh/sshd_config
по причине своей устарелости и дырявости.
SELinux relabel
Если используется SELinux, тогда создаём файл /.autorelabel
для автоматической перемаркировки всех файлов системы:
touch /.autorelabel
Выход из песочницы
exit
Заключительные операции
Объединение снэпшотов
umount -R ${SYSROOT}
lvconvert --merge /dev/vg/snap_var
lvconvert --merge /dev/vg/snap_root
stdout пример:
Delaying merge since origin is open.
Merging of snapshot vg/snap_var will occur on next activation of vg/var.
Stdout последних команд говорит о том, что объединение произойдёт на следующей активации lv-томов, то есть, в нашем случае, после перезагрузки сервера.
reboot
sync
sleep 10
reboot -f
После перезагрузки
В случае установленной на машине ОС ‘AltLinux 10’, потребуется ещё одна перезагрузка машины по той причине, что следы от ранее созданных сеэпшотов, по неясной причине, остаются в /dev/mapper/
, но не в /dev/vg/
.
reboot