300 ГБ исчезли за секунды: как проверить, что бэкап вернёт сервис вовремя

Инженер хотел заново настроить резервный сервер PostgreSQL и через несколько секунд остановил команду: она удаляла данные на основной базе. К этому моменту исчезли около 300 ГБ. Затем взяли резервную копию и выяснили, что привычный pg_dump завершался с ошибкой, а уведомления об этом не доходили.

Это случилось с GitLab.com. В публичном разборе инцидента описано, как для восстановления пришлось взять снимок шестичасовой давности. Перенос данных занял около 18 часов. Сервис вернулся, часть проектов, комментариев и учётных записей вернуть не удалось.

Привет, я Антон Фокин, CEO Qtim. В рабочем тесте мы проходим всю цепочку: поднимаем данные в отдельном окружении, запускаем приложение, проверяем критичный сценарий и измеряем время до готовности продукта. На примерах «Стадикэтс» и «Понимаю» покажу, какие вопросы эта проверка ставит перед большим сервисом.

RPO, Recovery Point Objective, задаёт допустимую потерю данных во времени. RTO, Recovery Time Objective, определяет предельную длительность восстановления. AWS Well-Architected рекомендует подтверждать оба показателя в ходе учений: RPO — по свежести восстановленной точки, RTO — по всему пути до готовности системы к работе.

В «Стадикэтс» мы объединили шесть образовательных курсов в одну платформу: с личным кабинетом, домашними заданиями, пробниками и статистикой прогресса. Для такого контура RPO и RTO обсуждают не абстрактно. Нужно решить, за какой интервал допустимо потерять отправленные задания, результаты пробников, покупки и изменения доступа к курсу. Ответ задаёт требования к данным и времени возврата критичных сценариев.

Допустим, интернет-магазин принимает заказы постоянно. RPO в 15 минут означает, что компания допускает потерю изменений максимум за этот интервал. При RTO в два часа критичный сценарий должен вернуться в строй в пределах этого срока. Эти значения служат условиями примера, а не универсальной нормой.

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

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

«Понимаю» — корпоративная платформа поддержки сотрудников с онлайн-консультациями разных специалистов. В таком сервисе критичным становится не только подъём базы: восстановленный продукт должен вернуть пользователю возможность войти по корпоративному доступу, увидеть запланированную встречу и подключиться к консультации.

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

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

Минимальное учение проводим по семи шагам:

1. Выбираем конкретный сервис, его RPO и RTO.

2. Берём точку восстановления по обычной производственной процедуре.

3. Запускаем таймер и разворачиваем отдельное окружение.

4. Проверяем целостность: контрольные суммы, количество записей и бизнес-инварианты.

5. Подключаем приложение и проходим один критичный пользовательский сценарий.

6. Фиксируем фактическую потерю данных и полное время до готовности.

7. Обновляем инструкцию, автоматизацию и владельцев по итогам учения.

Бизнес-инвариант зависит от продукта. В «Стадикэтс» для проверки полезно сопоставить доступ к курсу, факт оплаты, отправленное задание и результат пробника. Для «Понимаю» — доступ пользователя и корректность данных о запланированной консультации.

Инструкцию отдаём сотруднику команды, который её не писал. Во время аварии автор может быть недоступен, а двусмысленный шаг увеличит паузу. В документе оставляем команды, критерии результата и условия остановки.

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

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

Репликация помогает быстро переключиться при отказе узла. Ошибочное удаление или повреждение может уйти и на реплику. Для возврата к состоянию до события используем независимую точку восстановления с подходящим сроком хранения.

После каждого учения мы заполняем короткий паспорт результата: сервис и ответственного, точку и источник копии, целевые и фактические RPO/RTO, результат чтения данных, прохождение пользовательского сценария, найденные ограничения и дату следующего запуска.

AWS Prescriptive Guidance предлагает учитывать требования бизнеса и повторять тесты после существенных обновлений приложения или инфраструктуры. Поводом для внепланового прогона становятся рост объёма базы, смена версии СУБД, новый регион, ротация ключей, миграция хранилища и переработка критичного сценария.

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

1. Какие действия пользователей компания готова потерять и за какой интервал?

2. Через сколько должен заработать каждый критичный сценарий?

3. Где лежат копии и кто может их изменить или удалить?

4. Когда сервис в последний раз поднимали с нуля из сохранённой точки?

5. Какие RPO и RTO зафиксировали?

Мы считаем бэкап рабочим после тестового восстановления, проверки данных и фиксации фактических RPO и RTO. Без даты последнего учения и этих измерений заявленный срок остаётся ожиданием.

В Qtim бэкапы входят в инфраструктурный контур SaaS вместе с наблюдаемостью, SLA, дежурством и инструкциями для аварийных действий. Остальные составляющие собрали на странице о разработке SaaS-сервисов.

После остановленной команды мы уже знаем, из какой точки вернуть 300 ГБ и сколько займёт возврат системы в работу.