Учения по восстановлению сервера с нуля: как провести и что записать

MAATRIX

Проверка «бэкап разворачивается, файлы на месте» — необходимый минимум, но она отвечает только на один вопрос: цел ли архив. Она не отвечает на вопрос, который на самом деле решает судьбу инцидента — сможет ли команда за разумное время поднять с нуля весь сервер: ОС, сеть, секреты, сервисы, DNS, — имея на руках только бэкап и то, что написано (или не написано) в документации. Ниже — как спланировать и провести такие учения, не подставляя продакшен, и что обязательно записать по итогам, чтобы вторая попытка была быстрее первой.

Чем учения «с нуля» отличаются от проверки одного бэкапа

Ежемесячная проверка бэкапа — это, как правило, «взяли дамп базы, накатили на тестовый инстанс, свозили count(*), убедились, что данные не битые». Полезно, быстро, но проверяет один компонент в вакууме. Учения по восстановлению сервера с нуля моделируют другую ситуацию: сервер физически недоступен — диск умер, провайдер потерял VPS, аккаунт заблокирован, дата-центр сгорел, — и у вас нет ничего, кроме бэкапов данных, снапшотов конфигов (если они есть) и памяти команды.

Разница принципиальная:

Если в компании уже отлажена лёгкая ежемесячная проверка одного бэкапа — прекрасно, не бросайте её, она ловит порчу архивов рано. Но она не может поймать другой класс проблем: устаревшую инструкцию, забытый вручную шаг, секрет, который знает только уволившийся администратор, DNS-запись, прописанную три года назад руками и нигде не задокументированную. Эти проблемы всплывают только тогда, когда кто-то реально пытается собрать сервер заново по тому, что есть в наличии — а не по памяти того, кто его изначально настраивал.

Более лёгкий, часовой формат для одного конкретного сценария аварии (например, случайного удаления таблицы) описан в статье про часовую репетицию восстановления — это хороший первый шаг перед учениями «с нуля», если команда вообще ни разу не восстанавливалась из бэкапа. Учения из этой статьи — следующий уровень: не одна система, а вся инфраструктура целиком.

Почему восстановление проваливается не из-за бэкапа

Практика показывает: когда восстановление с нуля идёт не по плану, причина в самом бэкапе — редкость. Гораздо чаще ломается то, что вокруг него:

• Инструкция написана для другой версии. В README.md — команды для Ubuntu 20.04 и Docker Compose v1, а на новой машине по умолчанию ставится Ubuntu 24.04 и docker compose (v2, без дефиса), где часть флагов изменилась.
• Секрет существует только в голове или в 1Password конкретного человека. Пароль от БД, приватный ключ для деплоя, токен API — если он не лежит в общем зашифрованном хранилище, восстановление упирается в человека, который в отпуске или недоступен.
• Забытый шаг, который годами делался руками один раз при первой настройке. Классика — забыли, что нужно вручную создать пользователя БД с нужными правами до применения дампа, или что у сервиса systemd есть drop-in override в /etc/systemd/system/myapp.service.d/, который не входит ни в один бэкап, потому что «это же мелочь, и так помню».
• DNS и внешние зависимости не описаны. TTL старой A-записи ещё не истёк, и часть пользователей идёт на мёртвый IP; забыли про SPF-запись, привязанную к старому IP; забыли про whitelisting нового IP в firewall провайдера платежей.
• Скрипт деплоя зависит от состояния, которого больше нет. Скрипт предполагает, что /opt/app уже существует, что systemd-юнит уже создан — то есть он не идемпотентен и не разворачивает систему с нуля, а лишь обновляет уже настроенную.
• Порядок шагов нигде не зафиксирован. Восстановление БД до поднятия сервиса или после — не очевидный вопрос, если инструкция написана списком, а не пронумерованной последовательностью с явными зависимостями.

Каждый из этих пунктов не имеет отношения к качеству бэкапа как такового — бэкап может быть идеальным, а восстановление всё равно займёт в три раза больше времени или провалится, потому что документация и процедура вокруг него устарели. Именно это и должны ловить учения «с нуля»: не «бэкап цел», а «команда, вооружённая только документацией и архивами, реально может поднять систему заново».

Как спланировать учения, не создавая риск для продакшена

Главное правило — учения никогда не трогают боевой сервер напрямую. Восстанавливаете не «поверх» прода, а рядом, на изолированной инфраструктуре, и переключаете трафик (или не переключаете вовсе, если цель — только измерить время и найти пробелы) уже осознанно, отдельным решением.

1. Отдельная VM, не «донастроенный» staging. Staging, который годами правили руками, лжёт: он воспроизводит не состояние «с нуля», а состояние «staging, каким мы его случайно сделали». Для учений честнее взять почасовой VPS, снести после теста и не платить за простой.

2. Изоляция сети. Разверните новый сервер с другим IP, без прописывания production-домена в реальный DNS. Тестируйте по /etc/hosts на машине восстанавливающего (echo "1.2.3.4 example.com" | sudo tee -a /etc/hosts) или заведите тестовый поддомен вроде dr-test.example.com, указывающий на новый IP — так проверяется весь путь включая TLS, но боевой домен не трогается.

3. Копия данных, а не рабочая база. Восстанавливайте из бэкапа, а не репликацией с продакшена «вживую» — иначе учения превращаются в реальную миграцию с риском для мастер-базы. Если бэкапы шифрованные, заранее убедитесь, что ключ доступен не только тому, кто обычно проверяет бэкапы, но и «дежурному» на учениях.

4. Время и предупреждение команды. Учения — не внезапная тревога с реальными алертами ночью. Заранее зафиксируйте окно (например, вторник, 14:00-17:00) и предупредите тех, кто может получить алерты от мониторинга, если тестовый инстанс попадёт в общий scope проверок.

5. План отката. Если тестируете финальное переключение трафика на новый сервер, заранее понизьте TTL DNS-записи (за 24-48 часов, до 300 секунд) — чтобы при необходимости откат не растянулся на часы из-за кэширования резолверов.

6. Бюджет. Полноценные учения — это несколько часов работы 2-4 человек плюс стоимость временной инфраструктуры. Не бесплатно, но кратно дешевле реального инцидента, где то же восстановление идёт под давлением и без права на ошибку.

Сценарий: полная потеря сервера и восстановление на новой машине

Рабочий сценарий для команды, обслуживающей типичный стек (веб-приложение + БД + reverse proxy на одном или нескольких VPS). Отталкивайтесь от него, адаптируя под свою инфраструктуру.

Легенда для команды: «Сервер prod-01 недоступен необратимо: провайдер сообщил об аппаратном отказе. У нас есть последний файловый/образный бэкап, бэкап БД отдельно, доступ к DNS-панели и к хранилищу секретов. Задача — поднять работоспособную копию на новом сервере и задокументировать каждый шаг, которого не было в инструкции».

Пошагово:

1. Провижининг нового сервера. Закажите VPS того же (или совместимого) размера, с той же базовой ОС, что описана в документации. Зафиксируйте время старта — это T0.

   # базовая подготовка новой машины
   apt update && apt upgrade -y
   apt install -y curl wget git ufw fail2ban unattended-upgrades
   timedatectl set-timezone Europe/Moscow

1. Восстановление сети и firewall по документации, а не по памяти. Откройте регламент по документации сервера (или её аналог у вас) и буквально идите по пунктам: какие порты открыты, какие правила ufw/iptables, есть ли VPN или bastion-хост, привязан ли SSH-доступ к конкретным IP.

   ufw allow OpenSSH
   ufw allow 80,443/tcp
   ufw enable

1. Установка рантайма строго по версиям из документации, не «последние доступные» — расхождение версий Docker, Node.js, PostgreSQL часто и есть источник несовместимости с восстановленными данными.
2. Восстановление секретов из хранилища (Vault, зашифрованный .env, менеджер паролей команды) — отдельным шагом, до разворачивания сервисов. Зафиксируйте, сколько человек реально имели доступ к нужным секретам в момент учений.
3. Восстановление данных.

   # пример восстановления через restic в новое окружение
   export RESTIC_REPOSITORY=s3:https://s3.example.com/backups
   export RESTIC_PASSWORD_FILE=/root/.restic-pass
   restic snapshots
   restic restore latest --target /restore
   pg_restore -U postgres -d appdb /restore/db/appdb.dump

1. Разворачивание приложения по деплой-скрипту — важно тестировать именно скрипт из реального деплоя, а не ручные команды «как обычно делаем». Если скрипт предполагает уже существующее состояние (пользователи, каталоги, systemd-юниты) — это и есть пробел, который нужно найти сейчас.
2. Smoke test. Не «страница открылась», а конкретный список: логин работает, платёжный вебхук принимается, фоновые задачи (cron, очереди) запускаются, письма уходят через SMTP.
3. DNS и внешние зависимости — переключение тестового поддомена, проверка TLS-сертификата, проверка, что внешние интеграции (платёжный шлюз, email-провайдер) видят новый IP в whitelisting, если он у них настроен.
4. Фиксация T1 — момент, когда сервис реально работоспособен для конечного пользователя. Разница T1-T0 — это измеренный RTO для этого сценария, не оценочный, а фактический.

Отдельно стоит прогнать более узкий вариант этого же сценария — восстановление одной виртуальной машины из образа, без полной пересборки инфраструктуры вокруг: он описан в статье про восстановление VM из образа и может быть промежуточным шагом перед учениями полного цикла.

Роли, хронометраж и как измерять реальное RTO

Учения без чёткого распределения ролей превращаются в толпу, где все дают советы, а восстанавливает кто-то один. Минимальный набор ролей:

• Восстанавливающий — выполняет команды. На первых учениях им должен быть НЕ тот, кто изначально настраивал систему: так вскрывается, что часть знаний была неявной — «все же знают, что...» — и не попала в документацию.
• Хронометрист — фиксирует время каждого крупного шага отдельными засечками, а не только общий итог. Разбивка по шагам показывает, где реально теряется время.
• Наблюдатель-протоколист — не помогает руками, только записывает: какие команды не сработали как в документации, какие шаги придумывали на ходу.
• Ответственный за откат — следит, чтобы никто в панике (даже учебной) не тронул продакшен-ресурсы и не изменил боевые DNS-записи раньше согласованного момента.

Хронометраж стоит вести в простой таблице прямо во время учений:

Итоговая длительность строки «начало-конец» первого и последнего этапа — и есть измеренный RTO. Сравните его с тем RTO, который заявлен (или подразумевается) в SLA перед клиентами или внутри команды — часто оказывается, что заявленные «восстановимся за 2 часа» на практике превращаются в 6-8, потому что никто раньше не измерял это на практике, а считал только стоимость хранения бэкапов, что не то же самое, что стоимость и скорость их фактического восстановления.

Что фиксировать по итогам: протокол, пробелы, план исправлений

Учения без письменного разбора теряют почти всю ценность — через месяц никто не вспомнит нюансы, а в следующий раз наступят на те же грабли. Разбор проводите сразу после учений, пока детали свежи, в формате короткого документа (можно прямо в вики или таск-трекере):

1. Факты.

• Дата, сценарий, состав участников, роли.
• Измеренный RTO по этапам (таблица выше).
• Версия бэкапа, из которого восстанавливались, и его возраст на момент теста.

2. Что пошло не так — построчно, без сглаживания. Каждая строка — конкретная проблема, а не общее «в целом всё нормально, но были нюансы»:

• «Команда docker-compose up -d из README не сработала — на новой машине только docker compose (v2), потеряно ~12 минут на поиск замены».
• «Пароль от S3-бакета с бэкапами знал только X, он был недоступен первые 20 минут — секрет нужно продублировать в командном хранилище».
• «Nginx-конфиг ссылается на сертификат по пути /etc/ssl/custom/, который не входит ни в один бэкап — сертификат пришлось перевыпускать вручную».

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

4. Пробелы в процедуре/скриптах — отличайте от пункта 3: это не «не написали», а «написали неправильно» или «скрипт не идемпотентен». Такие пункты требуют правки кода (деплой-скрипта, Ansible-плейбука), а не текста.

5. Итоговый RTO против целевого — если целевое время восстановления не было явно согласовано заранее, самое время формализовать его по итогам первых честных учений.

6. Дата следующих учений — сразу, не «когда-нибудь»: без конкретной даты следующий прогон рискует не состояться в разумный срок — та же ловушка, о которой уже говорилось выше.

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

Частые вопросы