Developer

Disaster Recovery: бэкапы, PITR, RPO-RTO и учения восстановления

↑ Этап 7 · Эксплуатация и безопасность БД

По желанию~5 мин чтенияУровень: middle+

Зачем это на собесе

Высшая степень зрелости эксплуатации: план, процедуры и регулярные учения по восстановлению после катастроф.

Что такое Disaster Recovery

Набор планов и технологий для восстановления сервиса после тяжёлых сбоев: потеря дата-центра/региона, повреждение данных, ошибочное удаление, атака шифровальщика, ошибка оператора.

Отличие от HA: HA защищает от отказа отдельных узлов (автоматически, минуты). DR — от потери площадки или логического повреждения данных (часто вручную, часы).

Целевые показатели

  • RPO — допустимая потеря данных;
  • RTO — допустимое время недоступности;
  • RLO (Recovery Level Objective) — какой уровень функциональности восстановить в первую очередь.
УровеньRPORTOПодходСтоимость
Backup & restoreчасычасы–суткибэкапы + восстановлениенизкая
Pilot lightминутычасыминимальная инфраструктура в другом регионе, данные реплицируютсясредняя
Warm standbyсекунды–минутыминуты–часуменьшенная копия работаетвыше
Hot / active-active~0секунды–минутыполноценное в нескольких регионахмаксимальная

Показатели определяются бизнесом (стоимость простоя и потери данных), а не инженерами.

Сценарии катастроф

СценарийЗащита
Отказ узла / дискаHA (Patroni), RAID, реплики
Отказ зоны доступностиmulti-AZ
Потеря регионаDR-регион, standby cluster, бэкапы в другом регионе
Ошибочное удаление/UPDATE без WHEREPITR, логический бэкап, журнал, delayed replica
Повреждение данных (баг, bit rot)контрольные суммы (data_checksums), проверка бэкапов, PITR
Шифровальщик, злонамеренное удалениенеизменяемые бэкапы (Object Lock), изоляция учётных записей, offline-копия
Потеря ключей шифрованиярезервирование ключей в KMS/Vault
Ошибка миграциитранзакционные DDL, бэкап перед миграцией, roll-forward
Потеря облачного аккаунта/провайдеракопии в другом облаке/у другого провайдера

Компоненты решения

  1. Резервные копии: полные + инкрементальные + непрерывная архивация WAL (pgBackRest, WAL-G, Barman) → объектное хранилище в другом регионе, шифрование, Object Lock, политика ретенции, правило 3-2-1.
  2. PITR: восстановление на момент до инцидента (см. предыдущий раздел про бэкапы).
  3. Отложенная реплика (recovery_min_apply_delay = '1h'): защита от логических ошибок, быстрый откат.
  4. DR-реплика / standby cluster в другом регионе: асинхронная репликация (Patroni standby cluster, primary_conninfo на другой кластер).
  5. Инфраструктура как код: Terraform/Ansible/Helm — быстро поднять окружение заново.
  6. Данные вне БД: объектное хранилище (репликация бакетов), очереди, секреты, конфигурации, DNS.
  7. Runbook: пошаговые инструкции на случай каждого сценария, контакты, доступы (break-glass), решения о «точке невозврата».
  8. Мониторинг DR: лаг DR-реплики, успех бэкапов, архивации WAL, свежесть последней копии, проверки целостности.

Процедура восстановления (PITR-пример)

1. Зафиксировать инцидент и время (t_incident), остановить запись в повреждённую БД (режим read-only / отключить приложение).
2. Определить целевую точку: последний момент до ошибки.
3. Поднять НОВЫЙ экземпляр из последнего полного бэкапа + WAL (pgbackrest restore --type=time --target=...).
4. Проверить целостность и данные (контрольные запросы, счётчики, выборочный анализ).
5. Вариант A: выгрузить потерянные данные в рабочую БД (точечное восстановление).
   Вариант B: переключить трафик на восстановленный экземпляр (DNS/HAProxy), переподнять реплики.
6. Собрать метрики: фактический RTO/RPO, задержки.
7. Постмортем и улучшения.

Учения по восстановлению

Необходимы: непроверенный бэкап = отсутствие бэкапа.

УровеньЧтоЧастота
Автоматическая проверкаеженощное восстановление последнего бэкапа в песочницу + контрольные запросыежедневно
Tabletopразбор сценария за столом по runbookраз в квартал
Учение на стендеполное восстановление в изолированной среде, замер RTOраз в квартал/полугодие
Game Day (chaos)контролируемое отключение узла/зоны в staging или продераз в полгода
Failover DR-регионапереключение на DR с реальным трафикомраз в год

Что замерять: фактические RPO и RTO, время обнаружения, время принятия решения, ошибки в runbook, зависимости (DNS, секреты, сертификаты, доступы).

Особенности и ловушки

  • секреты и ключи недоступны в DR-регионе — восстановление невозможно;
  • зависимости от первичного региона (DNS, контейнерный реестр, CI);
  • согласованность БД и объектного хранилища (восстанавливать на одну и ту же точку);
  • версии ПО: тот же major PostgreSQL для физического восстановления;
  • лимиты ёмкости в DR-регионе (квоты облака) и стоимость;
  • задержка репликации в DR увеличивает RPO;
  • split-brain при возврате: «failback» — отдельная процедура;
  • документация в недоступной системе (runbook хранится в той же вики, что упала) — держите копию вне основной инфраструктуры;
  • людской фактор: паника, отсутствие доступов, непонятные роли.

Коммуникации и роли

Incident commander, техническая группа, коммуникации (статус-страница, клиенты), руководство; шаблоны сообщений; критерии объявления «катастрофы» и отката.

Связь с безопасностью и соответствием

Требования регуляторов (ЦБ, PCI DSS, ISO 27001, GDPR): план непрерывности бизнеса (BCP), регулярные учения, хранение копий, аудит.

Вопросы с ответами

Вид графа

Обратные ссылки