Материнская плата умерла, аренда в дата-центре закончилась, или диск отказал так, что рядом с ним не то что система - разметка не читается. Железо новое стоит на столе, бэкап есть, и единственный вопрос - как превратить архив в работающий сервер за вечер, а не за неделю ручной пересборки конфигурации. Ниже полный порядок действий: загрузка live-системы, разметка, распаковка хранилища BorgBackup либо перенос через rsync, восстановление загрузчика, сети и финальная проверка. Схема одинакова и для физического сервера, и для облачной машины, различаются только имена устройств.
Что должно быть в бэкапе чтобы восстановление уложилось в один вечер
Качество восстановления определяется задолго до сбоя, в момент настройки копирования. Стандартный набор утилиты резервного копирования - ядро проблемы: если скопированы только базы и каталоги пользователей, сервер собирать заново вручную. Полный слепок корня с BorgBackup или регулярный rsync закрывают почти всё, но и им нужен перечень мелочей, без которых вечер превращается в неделю.
Минимальный комплект для гарантированного восстановления выглядит так:
- полный архив корня либо как минимум /etc, /home, /var, /root и /usr/local;
- список установленных пакетов, снятый командой dpkg --get-selections или rpm -qa;
- ключи и пароль хранилища BorgBackup, сохранённые вне сервера;
- схема разметки диска, конфигурация LVM и mdadm, зафиксированные заранее;
- короткая проверенная процедура восстановления, опробованная на тестовой машине.
Снимаются эти детали одной парой команд и уходят в надёжное место рядом с архивом:
dpkg --get-selections > packages.txt
rpm -qa > packages-rpm.txtЕсли полного архива корня нет и восстановление идёт из частичного, список пакетов становится главным инструментом: свежая система ставится из установщика, затем dpkg --set-selections < packages.txt с последующим apt-get dselect-upgrade подтягивает набор ПО, а поверх возвращаются сохранённые /etc и данные. Это дольше распаковки слепка, но на порядок быстрее попыток вспомнить, какие пакеты обеспечивали работу мониторинга и почты.
Для BorgBackup в режиме keyfile ключ выгружается отдельно от репозитория командой borg key export, и без этой копии архив превращается в зашифрованный мусор. Проверенный практикой совет - ежегодная репетиция: раз в год восстановите копию на виртуальную машину и засеките время. Репетиция вскрывает дыры быстрее любой теории: потерянный пароль, ключ на сгоревшем сервере, архив без /etc/ssh, после которого на новую машину не попасть.
Загрузка нового железа с live ISO и разметка диска
Удобнее всего SystemRescue: в наборе уже есть borgbackup, rsync, chroot-инструменты и поддержка сети из коробки. Подойдёт и live-образ Ubuntu с установкой нужных пакетов вручную. Сразу после загрузки поднимите сеть, включите ssh-сервер и смените пароль root - работать длинными командами через консоль IPMI можно, но неудобно.
Разметка обязана повторять режим загрузки старого сервера. Если система стояла на UEFI, нужен GPT и раздел EFI; если на классическом BIOS - достаточно MBR. Типовой вариант для UEFI:
parted /dev/sda mklabel gpt
parted -a optimal /dev/sda mkpart ESP fat32 1MiB 513MiB
parted /dev/sda set 1 esp on
parted -a optimal /dev/sda mkpart root ext4 513MiB 100%
mkfs.vfat -F32 /dev/sda1
mkfs.ext4 /dev/sda2
mount /dev/sda2 /mnt/restore
mkdir -p /mnt/restore/boot/efi
mount /dev/sda1 /mnt/restore/boot/efiЕсли старый сервер использовал LVM, повторите структуру: pvcreate на разделе, vgcreate с прежним именем группы, lvcreate с прежними именами томов - тогда fstab восстанавливаемой системы не потребует правки в части путей. Точку монтирования /mnt/restore в дальнейшем тексте считаем корнем будущей системы.
Выбор между восстановлением из Borg и переносом через rsync
Инструменты решают разные задачи, и выбор зависит от состояния источника. Borg хорош, когда исходной машины больше нет: хранилище автономно, архивы дедуплицированы, сжаты и лежат на отдельном сервере или внешнем диске. rsync незаменим, когда источник жив: перенос идёт напрямую, без промежуточного архива, а повторные прогоны забирают только изменения. На практике их часто комбинируют: репетиции и базовый перенос делают через Borg, а разницу в последние часы догоняют коротким rsync по сети.
Кстати о дедупликации: хранилище Borg хранит каждый уникальный кусок один раз, поэтому ежедневные слепки корня занимают место, сравнимое с реальным объёмом изменений за сутки. Это же свойство делает восстановление изредка капризным: архивы зависят от общих кусков, и удалять старое без borg prune, проверив политику хранения, не стоит - prune сам сохранит заданное число суточных, недельных и месячных копий.
Распаковка архива BorgBackup на подготовленный корень
Задайте переменные окружения, чтобы не вводить параметры в каждой команде:
export BORG_REPO="ssh://Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. :2222/srv/backup/mail"
export BORG_PASSPHRASE="пароль-хранилища"
borg list --format "{archive} {time} {comment}"Список покажет архивы с датами; выберите последний рабочий, а не последний созданный - сбой мог произойти посреди копирования. Перед большой распаковкой полезна сверка целостности: borg check --repository-only быстро проверяет сегменты хранилища, а borg diff между двумя последними архивами покажет, что менялось перед сбоем.
Дальше два равноправных пути. Первый - монтирование: borg mount /mnt/borg поднимет хранилище как файловую систему, где каждый архив лежит отдельным каталогом, оттуда содержимое переносится обычным rsync. Второй - прямая распаковка:
cd /mnt/restore
borg extract ::mail-2026-05-10 -v --progressРаспаковку выполняйте от root: тогда сохраняются жёсткие ссылки, расширенные атрибуты, списки контроля доступа и владелец файлов, без которых восстановленный сервер ведёт себя странно. Если архив делался с префиксом пути, снимите его ключом --strip-components с нужной глубиной. Системные каталоги /proc, /sys, /dev и /run в грамотном архиве отсутствуют, они создаются ядром при загрузке; если старый скрипт копирования тащил их внутрь архива, при распаковке просто пропустите.
Пара страховок на случай неровностей. Если предыдущая операция с хранилищем оборвалась, репозиторий остаётся под замком, и снять его помогает borg break-lock - применять только когда точно известно, что других сессий нет. А чтобы старые архивы не пострадали от проблем на исходном сервере, хранилище настраивают в режиме append-only: копирование работает, а перезапись и удаление истории запрещены, снимается режим вручную командой borg compact уже на стороне резервного сервера.
Перенос системы с живого диска через rsync с сохранением прав
Если старый сервер ещё грузится или его диск подключили к рабочей машине через переходник, переезд делается rsync без всяких архивов. Формула переноса:
rsync -aHAXx --numeric-ids --info=progress2 -e "ssh -p 22" Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. :/ /mnt/restore/Разберём флаги, потому что каждый из них отвечает за работоспособность результата: -a сохраняет права, владельцев и времена; -H тащит жёсткие ссылки, без него каталоги с линковками раздуются; -A и -X переносят списки доступа и расширенные атрибуты; -x не даёт вылезать за пределы одной файловой системы; --numeric-ids переносит идентификаторы пользователей как числа, не ища совпадений имён; --info=progress2 рисует общий прогресс вместо бегущего по файлам. Исключения обязательны, иначе в новый корень утащатся виртуальные каталоги и чужие монтирования:
--exclude='/proc/*' --exclude='/sys/*' --exclude='/dev/*' --exclude='/run/*' --exclude='/tmp/*' --exclude='/mnt/*'Если в старой системе были отдельные разделы /boot или /var, повторите rsync для каждого, ключ -x сам остановится на границе. Финальный проход делают с ключом --delete и на остановленных сервисах: базы и почтовые хранилища корректнее снять штатным дампом, чем копировать файлы на лету. Хорошая схема - один полный прогон накануне и один короткий в окно остановки: второй переносит только изменения и занимает минуты. Проверкой служит холостой прогон с ключом -n: он сравнивает стороны и показывает, что осталось, не трогая ни одного файла; пустой вывод после финального переноса означает, что копия точна до последнего байта.
Приведение fstab GRUB и сети в порядок на новом железе
Распакованные файлы описывают старое железо, и теперь расхождения лечатся точечно. Первое - устройство корня: blkid покажет новые идентификаторы, впишите их в /mnt/restore/etc/fstab взамен старых UUID. Заодно проверьте /etc/crypttab и конфигурацию mdadm, если массивы были. Второе - сеть: имена интерфейсов на новой машине другие, смотрите их командой ip link и правьте конфигурацию netplan в /etc/netplan или interfaces в /etc/network. У старых систем встречается файл /etc/udev/rules.d/70-persistent-net.rules, привязывающий имена к старым MAC - его удаляют. И очистите /etc/machine-id, обнулив файл: иначе новая машина начнёт жизнь с идентичностью старой и получит от DHCP тот же адрес.
Третье - загрузчик. Подмонтируете виртуальные каталоги и заходите в будущую систему:
for d in dev proc sys run; do mount --bind /$d /mnt/restore/$d; done
chroot /mnt/restore
grub-install /dev/sda
update-grub
update-initramfs -uНа UEFI вместо этого вызывается grub-install с ключами --target=x86_64-efi и --efi-directory=/boot/efi, порядок загрузочных записей подскажет efibootmgr. Для систем на базе SUSE и Fedora конфигурация загрузчика собирается командой grub2-mkconfig -o /boot/grub2/grub.cfg, а образ initramfs - dracut --force. Выходя из chroot, размонтируйте всё в обратном порядке. Хост-ключи ssh разумно сохранить из архива: клиенты не увидят предупреждений о подмене ключей, а authorized_keys переедет вместе с /etc/ssh и /root сам.
В этом же блоке не забудьте мелочи, о которых вспоминают уже после ввода в работу: swap в fstab со старым UUID остановит загрузку с приглашением о неизвестном устройстве; /etc/resolv.conf и статические маршруты переедут из архива, но заслуживают проверки; часовой пояс и hostname живут в /etc/timezone и /etc/hostname, после смены железа их сверяют в первую же загрузку.
Контрольная проверка восстановленного сервера перед возвратом в работу
Первая загрузка - момент истины, и встречать её лучше с открытым доступом к консоли. Если система ушла в emergency mode, журнал подскажет причину: journalctl -b -p err выведет строки, из-за которых systemd остановил подъём. Дальше сверяйте список упавших служб командой systemctl --failed и слушающие порты через ss -tulpn с сохранённым списком портов старого сервера - расхождение быстрее находить по списку, чем по жалобам пользователей.
Отдельно пройдитесь по планировщикам: crontab -l для root и содержимое /etc/cron.d из архива. Проверьте правила брандмауэра, они переезжают вместе с /etc, но зависят от имён интерфейсов, которые вы поменяли. Базы данных поднимите из дампов и сверьте контрольные суммы ключевых таблиц. Сертификаты TLS переедут из архива, проверьте у них срок действия. И сразу настройте резервное копирование новой машины: BorgBackup ставится, ключи выгружаются в хранилище секретов, первый архив создаётся до ввода в работу, а не после.
Старый диск и старые архивы не спешите убирать: держите их нетронутыми пару недель, пока новая машина не проработает под реальной нагрузкой. Восстановленный сервер - это копия, снятая в стрессовый момент, и странности в ней всплывают не сразу.
Переключение на новую машину делайте последним шагом и обратимым: пока DNS или балансировщик указывают на старый адрес, новая система спокойно проходит обкатку, а откат - одна правка записи. Так смена железа перестаёт быть событием с неизвестным финалом и становится плановой работой с контрольными точками.
Финальный штрих - журнал восстановления: запишите, что не сработало, сколько времени занял каждый этап и какие файлы потеряны между последним архивом и сбоем. Такой документ бесценен для следующей аварии и для разговора с руководством. И планируйте следующую репетицию не реже раза в год: восстановление - навык, который без практики ржавеет быстрее, чем кажется.