Старый сервер умер безвозвратно - материнская плата сгорела, облако закрылось, пожар в стойке, неважно. Что важно - бэкап существует, и в этом случае полная потеря сервера перестаёт быть катастрофой и становится рабочей задачей на вечер: поднять новое железо, развернуть на нём содержимое из архива, донастроить то, что в архив не входило, и вернуть сервисы в строй. В этой статье - полный workflow такого восстановления: подготовительные требования, два пути через rsync и borgbackup, список того, что в бэкап не попадает, и дисциплина проверок, отличающая восстановление сервера от восстановления иллюзии.
Что значит полный restore и что он требует заранее
Восстановление сервера целиком - это не одна команда, а воспроизведение машины по сохранившимся данным. Полный бэкап сервера - это архивы файловых систем, плюс внешние ресурсы: база данных снята штатным дампом или снимком, конфигурация сети записана, список пакетов сохранён, а ключи и секреты лежат в хранилище, а не только на умершей машине. Восстановление без этих внешних элементов всегда неполно: голый rsync каталога / вернёт файлы, но не вернёт работающую систему.
Отсюда требования к бэкап-политике, которые проверяются именно в момент беды: бэкап хранится вне сервера; схемы LVM, RAID и разметки задокументированы; список сервисов и их настройки внешних ресурсов описан в runbook. Бэкап, который никогда не восстанавливался, считается непроверенным - это старое правило сохраняет актуальность десятилетиями, потому что проверка восстанавливаемости важнее проверки существования.
Подготовка нового железа и окружения
Новая машина загружается с live-образа или минимальной установкой - задача этого этапа не настроить систему, а подготовить приёмник: сетевые настройки для переноса данных по сети, разметка дисков под будущую систему, файловые системы созданы и смонтированы в /mnt. При заметно отличающемся железе решается вопрос совместимости: ядро в бэкапе должно поддерживать новые контроллеры, и при крупном технологическом скачке правильнее поднять чистую систему и переносить данные и конфиги, а не наоборот.
И далее - момент истины: смонтированный /mnt - это заготовка нового корня, и весь перенос сводится к заполнению этого каталога содержимым из бэкапа и последующей настройке загрузки.
Восстановление через rsync по шагам
Классический путь - rsync по сети с мёртвого бэкапа или из старого образа. Источником служит внешнее хранилище бэкапов, смонтированное по SSH или NFS, и команда переноса выглядит так: rsync -aHAXx --numeric-ids --info=progress2 <источник>/ /mnt/. Флаги неслучайны: -a сохраняет права и времена, -H жёсткие ссылки, -A списки контроля доступа, -X расширенные атрибуты, --numeric-ids сохраняет численные идентификаторы владельцев без попытки сопоставить имена на приёмнике - критично при восстановлении на систему без исходных пользователей.
Перенос идёт от корня к деталям, исключая то, что принадлежит живому окружению: псевдофайловые системы proc и sys, устройства из /dev и точка монтирования tmpfs. При переносе из образа все эти каталоги исключаются ключами --exclude с явным списком, и потому перед стартом стоит один раз прогнать команду с --dry-run, чтобы увидеть список исключений глазами, а не предполагать его.
После переноса проверяется объём: du на приёмнике против источника, потому что тихо оборвавшийся rsync в ночи - классика жанра, и лучший момент узнать об этом - до, а не после перезагрузки.
Восстановление через borgbackup
Borg добавляет к переносу дедупликацию и шифрование, и потому в зрелых инфраструктурах предпочитают именно его. Репозиторий бэкапов живёт на внешнем хранилище, и восстановление начинается с его подключения: borg mount <репозиторий> /mnt/borg или прямое извлечение через borg extract в подготовленный /mnt. Монтирование даёт удобный осмотр содержимого перед извлечением; extract выполняет перенос быстрее и без контекста FUSE.
Ключевое отличие от rsync - инкрементальность: borg хранит снапшоты, и восстановление - это выбор нужного снапшота по дате из borg list, а затем извлечение его целиком. Вредные привычки на этом этапе - взять самый старый снапшот по забывчивости или пропустить проверку ключа шифрования: парольная фраза и ключи репозитория должны лежать вне сервера, и их доступность проверяется до старта восстановления, потому что репозиторий без ключа - это красиво упакованная бесполезность.
Что не входит в бэкап и требует рук
Даже полный rsync каталога / не восстанавливает всё. Системные вещи, живущие вне файловых систем: разметка и загрузчик, о которых следующий раздел. Сетевые идентичности: MAC-адрес нового железа другой, и где-то может быть привязка по нему. Криптография host-ключей SSH имеет смысл обновить: сервер с чужими host-ключами после восстановления заставит всех клиентов переподомнить их - что, впрочем, честнее, чем сохранить старые без обновления.
Внешние ресурсы: обратные DNS-записи, привязки в мониторинге, сертификаты с привязкой к железу. Секреты из менеджера секретов - они должны быть в наличии, и доступ к ним не должен зависеть от восстанавливаемого сервера. Каждый пункт этого списка - одна строка в runbook процедуры восстановления, и именно эти строки превращают вечер в вечер, а не в сюрприз за сюрпризом.
Переустановка загрузчика и первый старт
Заполненный корень не грузится сам - ему нужен загрузчик. Процедура знакома по другим темам этой серии: bind-монтирование /dev, /proc и /sys в /mnt, chroot /mnt, затем grub-install с указанием диска и grub-mkconfig -o /boot/grub/grub.cfg. Для UEFI - с явным указанием ESP и проверкой наличия каталога EFI. При LVM - активация групп перед всем остальным, при LUKS - знание пароля и правка /etc/crypttab под фактическое имя нового устройства.
После выхода из chroot и перезагрузки наступает момент истины - сервер грузится в восстановленную систему или попадает в rescue shell, и в обоих случаях есть материал для работы: первая загрузка обычно проясняет все несовпадения нового железа с ожиданиями старой конфигурации.
Проверка целостности как обязательный этап
Восстановление считается завершённым не по факту загрузки, а по факту пройденной проверки. Список невелик: все сервисы поднялись и отвечают systemctl --failed пустым списком; данные на месте - ключевые каталоги просмотрены; базы отвечают и прошли быструю проверку целостности; сетевые интерфейсы поднялись с ожидаемыми адресами; мониторинг увидел сервер и снял зелёный статус. Пятнадцать минут на проверку - и восстановление получает статус подтверждённого, а не предположенного.
Регламентные тренировки восстановления
Единственная гарантия, что реальное восстановление пройдёт гладко - периодическая тренировка. Раз в квартал - на тестовом стенде или в облачном шаблоне - выполняется полный цикл: свежий бэкап разворачивается на чистую машину по памятке из runbook, и расхождения фиксируются сразу, пока свежи. Это единственный способ узнать, что в бэкапе не хватает нового сервиса, добавленного полгода назад, и что команда restore забыла один флаг - в мирной обстановке, а не в ночь аварии.
История из практики
Характерный случай: дата-центр объявил о закрытии площадки, а у клиента там жил сервер без виртуализации. Бэкапы через borg свежие, runbook отработан на тренировке, новое облако выбрано заранее. Вечер переезда: поднятие чистой машины, монтирование репозитория, borg extract последнего снапшота, bind-монтирование и chroot, grub-install, первый старт с правкой сети под новую среду. Три часа от нуля до работающего сервера, из которых час - перенос данных, а остальное - настройка окружения. На утро клиент заметил переезд только по смене IP-адреса в отчёте - и это лучший отзыв, какой вообще возможен для процедуры полного восстановления.
Памятка
Финальный порядок всей темы: внешний бэкап проверен и доступен; новое железо загружено в live или минимальной системе; разметка и файловые системы подготовлены; перенос через rsync с полным набором флагов или borg extract выбранного снапшота; загрузчик переустановлен из chroot; после старта - полный круг проверок; расхождения - в runbook для следующей тренировки. Это финальный рубеж инфраструктурной дисциплины: серверы приходят и уходят, а воспроизводимость восстановления - остаётся, и именно она отличает инфраструктуру от коллекции ручных работ.
Borg как выбор зрелых инфраструктур
Коротко о том, почему borg заслужил место в заголовке этой статьи наравне с rsync. Дедупликация на уровне блоков делает ежедневные бэкапы лёгкими: полный снимок весит новые изменения, и потому хранить полсотни поколений сервера стоит копейки по сравнению с полной копией каждого. Шифрование клиентской стороной защищает репозиторий от компрометации хранилища. Проверка целостности borg check - штатная команда, а не ритуал. И сжатие zstd из коробки ускоряет и перенос, и хранение. Всё это превращает borg из инструмента энтузиастов в стандарт де-факто для тех, кто проверяет свою инфраструктуру практикой восстановления, а не верой.
Проверка бэкапов без полного восстановления
Между тренировками существуют лёгкие ежедневные проверки, поддерживающие уверенность без больших затрат. Список содержимого свежего снапшота - borg list и сравнение с прошлым: расхождения по объёмам сразу видны. Точечное извлечение одного файла из последнего архива - borg extract с ограничением пути - убеждает в читаемости данных за минуту. Мониторинг успеха ночного задания - алерт при пропуске задачи, а не молчаливое доверие расписанию. Эти три привычки по пять минут каждая закрывают самый опасный разрыв в любой бэкап-стратегии - время между тихой поломкой бэкапа и её обнаружением.
Финальный аккорд всей серии
Эта статья закрывает последний рубеж цикла - восстановление сервера целиком, когда всё остальное из этой серии уже не помогло: загрузчик чинили, диски заменяли, разделы восстанавливали, а сервер всё равно ушёл. И главный её вывод работает на весь цикл: каждая тема серии - от профилактики до восстановления - это слой готовности, и вместе они складываются в инфраструктуру, где нет безвыходных вечеров. Серверы умирают, диски изнашиваются, обновления ломают - но за каждым таким событием стоит отработанная процедура с известным финалом. Именно это и называется зрелой эксплуатацией: не отсутствие аварий, а наличие маршрута для каждой из них.
Пусть все ваши восстановления остаются тренировками, а вчерашняя статья про заполненный корень - самым страшным инцидентом квартала. Спокойных дежурств, надёжных бэкапов и проверенных восстановлений - всему циклу читателей этой серии.
Что делает восстановление быстрым на самом деле
Опытные инженеры знают главный секрет этой темы: скорость восстановления определяется не скоростью переноса данных, а полнотой runbook. Перенос идёт своим ходом часами, и всё это время инженер либо выполняет заранее записанные шаги параллельно, либо импровизирует и теряет время на каждом повороте. Runbook с точными командами, списком внешних зависимостей и чек-листом проверок превращает окно переноса в конвейер: пока данные едут по сети, настраивается загрузчик, готовится сеть, сверяются секреты. Именно поэтому тренировка восстановления из предыдущего раздела окупается многократно - она не только проверяет бэкап, но и шлифует runbook до состояния сценария, который исполняется в фоне почти без участия человека.
И с этим пониманием серия про восстановление закрывается: от загрузочной флешки в начале блока до полного переноса сервера в его финале, каждый уровень готовности строится на предыдущем и делает следующий дешевле. Такова арифметика зрелой эксплуатации.
Всем надёжных бэкапов, проверенных восстановлений и пусть эта статья останется в закладках навсегда - просто на всякий случай.