Репетиция восстановления: сценарий учений на час

MAATRIX

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

Почему «когда-нибудь» не наступает

Проблема не в лени и не в нехватке ресурсов. Проблема в том, что «проверить восстановление» — это не задача, а расплывчатое намерение. У расплывчатого намерения нет длительности, нет чек-листа, нет ответственного с конкретным набором шагов — поэтому оно всегда проигрывает конкурс приоритетов задачам, у которых есть срок и понятный объём работы.

Решение — не «выделить время на восстановление», а провести конкретные учения на 60 минут по фиксированному сценарию. Это не полноценный disaster recovery drill с имитацией отключения дата-центра и оповещением клиентов — это малая, повторяемая тренировка на одну систему и один тип аварии. Она не заменяет bekap-vsego-servera-celikom для действительно критичной инфраструктуры, но снимает barrier входа: команда один раз проходит весь цикл и видит, что это управляемо и укладывается в час.

Если в вашей компании уже настроено резервное копирование, но реальное восстановление из него ни разу не тестировалось — этот план для вас. Если бэкапы вообще не настроены — сначала решите эту задачу (см. poshagovaya-nastrojka-vps-pod-bekapov-i-arhiva-s-nulya), учения без исходного материала для восстановления не имеют смысла.

Минуты 0-10: выбор одного конкретного сценария аварии

Это самый недооценённый шаг. Команда, которая садится «проверить восстановление вообще», за первые 10 минут обсуждения решает проверить сразу базу данных, конфиги, весь сервер и заодно накатить обновления — и в итоге не успевает ничего до конца. Правило первых 10 минут: выбрать РОВНО ОДИН сценарий и зафиксировать его письменно (даже в общем чате, одной строкой).

Три готовых варианта сценария, каждый реалистичен и типичен:

Сценарий А — случайное удаление таблицы БД. Кто-то из разработчиков выполнил DELETE FROM orders WHERE ... без WHERE id = ... или уронил таблицу миграцией. Проверяется: point-in-time восстановление или восстановление из последнего дампа конкретной базы.

Сценарий Б — полный отказ сервера. Диск умер, провайдер потерял VPS, случился необратимый апгрейд ОС. Проверяется: разворачивание системы с нуля на другой машине из полного бэкапа (образ или файловый бэкап + конфиги).

Сценарий В — повреждение конфигурации. Кто-то отредактировал nginx.conf, docker-compose.yml или конфиг приложения, система не стартует, а git-истории для отката нет (или в бэкап входят не только данные, но и конфиги). Проверяется: восстановление конкретных файлов конфигурации из архива на нужную дату.

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

Последние 2-3 минуты этого блока — определите роли: кто выполняет восстановление (именно он сегодня «дежурный», см. ниже про ротацию), кто засекает время, кто ведёт протокол разбора в четвёртом блоке.

Минуты 10-30: восстановление в изолированное окружение с секундомером

Это ядро учений. Ключевое слово — изолированное. Ни в коем случае не тренируйтесь поверх продовой системы: поднимите отдельную тестовую VM или контейнер, куда прилетит восстановленная копия. Дешёвый почасовой VPS для этого подходит идеально — поднял, прогнал сценарий, снёс.

Дальше — по выбранному сценарию:

Для сценария А (БД):

# на изолированном тестовом сервере
scp backup-server:/backups/mysql/orders_2026-08-30.sql.gz .
gunzip orders_2026-08-30.sql.gz
mysql -u root -p test_restore_db < orders_2026-08-30.sql

Если используется mysqldump с --single-transaction и бинарные логи для point-in-time — накатите дамп, затем примените binlog до нужной секунды (mysqlbinlog --stop-datetime="2026-08-30 14:32:00"). Если стек на PostgreSQL с pgbackrest или Percona XtraBackup — команды другие, но принцип тот же: полное восстановление в тестовую базу, не в прод.

Для сценария Б (весь сервер):

# восстановление из образа/снапшота на новый VPS
qemu-img convert -O raw backup-image.qcow2 /dev/vda
# или через Proxmox Backup Server / borgbackup extract, в зависимости от инструмента
borg extract /backups/repo::2026-08-30-full

Важно поднять на другой машине, а не переиспользовать исходную — иначе учения не проверяют реальный disaster recovery, а просто раскладывают файлы туда же, где они уже лежат.

Для сценария В (конфиги):

tar -xzf configs-2026-08-30.tar.gz -C /tmp/restore-test/
diff -r /tmp/restore-test/etc/nginx /etc/nginx

Главное правило этого блока: включите секундомер в момент старта команды восстановления и остановите его, когда данные физически появились на диске — не когда «вроде готово», а по факту завершения команды/скрипта. Запишите точное время (например, «17 минут 40 секунд»), а не прикидку «минут пятнадцать где-то». Разница между оценкой и фактом — обычно и есть самое ценное открытие учений: почти всегда реальное время оказывается больше ожидаемого, потому что забыт шаг с правами доступа, версией инструмента на новой машине или паролем, который «где-то был записан».

Если в отведённые 20 минут восстановление не укладывается — это не провал учений, это их главный результат. Остановитесь по таймеру, зафиксируйте, на каком шаге застряли, и разбирайте это в четвёртом блоке.

Минуты 30-50: функциональная проверка, а не просто «файлы появились»

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

Чек-лист по типу системы:

Практически это выглядит так: после восстановления БД в тестовое окружение — поднимите рядом тестовый инстанс приложения (даже минимальный, в Docker), укажите ему на восстановленную базу и откройте страницу, которая реально читает эти данные. Если это интернет-магазин — откройте карточку конкретного заказа, который был создан незадолго до момента бэкапа, и убедитесь, что он на месте со всеми полями. Если это CRM — найдите конкретного клиента и проверьте, что последние заметки по нему не потеряны.

Для сценария с конфигами функциональная проверка — это не diff, показавший отличия, а реальный перезапуск сервиса с восстановленным конфигом и проверка, что он поднялся и отвечает на нужном порту с ожидаемым поведением (не только systemctl status active, а конкретный запрос через этот конфиг).

Зафиксируйте результат в одном предложении по каждому пункту: «данные за август видны — да/нет», «сайт открывается и показывает актуальный каталог — да/нет». Это то, что попадёт в протокол разбора.

Минуты 50-60: разбор с командой и обновление документации

Последний блок — не формальность, а то, ради чего вообще стоило тратить час. Соберите всех, кто участвовал (или хотя бы дежурного и наблюдателя), и пройдитесь по четырём вопросам:

• Что прошло гладко? Зафиксируйте это тоже — если процедура документирована и команды сработали с первого раза, это подтверждает, что документация актуальна, и это стоит записать явно, а не считать самоочевидным.
• Что заняло больше времени, чем ожидалось? Сравните секундомер с тем, что закладывали в SLA или в голове («думали, минут 10, вышло 35»). Это конкретная цифра для пересмотра RTO (Recovery Time Objective), если он вообще формализован.
• Какие шаги были непонятны или недокументированы? Именно здесь чаще всего всплывает: «пароль от бэкап-хранилища знает только Вася», «в документации написано restic restore latest, а на деле нужен ещё flag --target», «в спецификации не указано, что конфиг нужно перезапускать в определённом порядке».
• Что нужно исправить в документации/скриптах прямо сейчас? Не «когда-нибудь», а в течение этого же дня, пока детали свежи. Даже одна строчка, добавленная в runbook сразу после учений, стоит больше, чем абзац, написанный через неделю по памяти.

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

Периодичность и почему дежурного нужно менять

Разумная частота учений зависит от критичности системы:

• Критичные системы (то, от чего зависит выручка или доступность сервиса для клиентов) — раз в квартал, а лучше раз в 4-6 недель, особенно после значимых изменений в инфраструктуре (миграция на новый сервер, смена инструмента бэкапа, обновление мажорной версии БД).
• Некритичные вспомогательные системы (внутренние дашборды, staging-окружения, редко используемые сервисы) — двух раз в год вполне достаточно, если между учениями не происходит серьёзных изменений в том, как эти системы бэкапятся.
• После любого изменения в схеме бэкапов (сменили инструмент, перенесли хранилище, изменили расписание) — внеплановые учения в течение 2-4 недель, не дожидаясь календарного срока. Смена инструмента — самый частый источник тихо сломанных бэкапов: perehod-s-samopisnogo-bekapa-na-instrument разбирает типичные грабли такого перехода.

Отдельное и, пожалуй, самое важное практическое правило — ротация дежурного. Соблазн поручать восстановление одному и тому же senior-инженеру, который «и так всё знает и сделает быстрее», понятен, но именно он убивает смысл учений. Если процедуру может выполнить только один конкретный человек, у вас нет процедуры восстановления — у вас есть один человек, который держит её в голове, и который однажды будет в отпуске, уволится или окажется недоступен именно в момент реальной аварии.

Поэтому:

• Назначайте дежурным по очереди РАЗНЫХ членов команды, включая менее опытных — цель учений в том числе проверить, что документация написана достаточно понятно для того, кто делает это впервые.
• Senior-инженер на таких учениях — наблюдатель и автор правок в документацию, а не исполнитель. Если он видит, что дежурный запутался на шаге, который самому senior'у кажется очевидным — это сигнал дописать этот шаг в runbook, а не молча взять клавиатуру в свои руки.
• Если дежурный не смог пройти сценарий за отведённое время без сторонней помощи — это провал документации, а не провал дежурного. Формулируйте это именно так в разборе, иначе люди начнут избегать роли дежурного из страха выглядеть некомпетентными, и ротация перестанет работать.

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

Что подготовить заранее, чтобы час не потратился впустую

Чтобы 60 минут ушли на сами учения, а не на поиск доступов, подготовьте до начала:

• Доступ к актуальному бэкапу (проверьте дату последнего успешного бэкапа — учения на заведомо устаревшей копии бессмысленны, см. также разбор случая, когда bekapy-shli-god-i-okazalis-nerabochimi).
• Изолированное тестовое окружение, поднятое заранее (отдельный VPS или контейнер) — не тратьте время учений на аренду и настройку с нуля.
• Пароли и ключи доступа к хранилищу бэкапов — под рукой у дежурного, а не только у того, кто их когда-то настраивал.
• Секундомер или таймер, видимый всем участникам — телефон, таймер в календаре, что угодно измеримое.
• Шаблон протокола разбора — простой документ с четырьмя вопросами из четвёртого блока, куда сразу вписываются ответы, а не «обсудим и кто-нибудь потом запишет».

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