Перейти к содержанию

Disaster Recovery, RPO и RTO

Раздел 04 · Типы достоверности

Тип материала: инженерный разбор. Схемы и примеры иллюстративные. Рекомендации — INFERENCE; учебные параметры — HYPOTHETICAL.

Проверка источников: 2026-11-02. Версии и границы первоисточников перечислены в конце. Documented contracts не означают выполненный runtime test.

Принцип работы и границы

Backup сохраняет восстанавливаемую историю, replication поддерживает копию состояния, DR объединяет восстановление данных, services, identities, dependencies и business invariants. Реплика быстро переносит логическое удаление; она не заменяет isolated backups.

FACT: PostgreSQL PITR требует подходящего base backup и непрерывной цепочки WAL до целевой точки. PostgreSQL 17 PITR. INFERENCE: RPO задаёт допустимую потерю принятых данных по конкретной системе, RTO — срок восстановления оговорённого сервиса до критериев готовности. Настройка «backup ежедневно» не измеряет ни то ни другое.

Раздельно оценивайте local commit durability, межрегиональную репликацию, credentials/KMS, schema registry и replay archives. Восстановление PG к старому cut при более новом consumer offset создаёт пропуски; восстановление idempotency store без effects создаёт ложные duplicates.

Иллюстративная архитектура

flowchart LR
 P[Primary writes] --> R[Replica]
 P --> W[Archived WAL]
 B[Isolated base backup] --> N[Isolated restore]
 W --> N
 N --> V[Invariant and dependency checks]
 V --> C[Controlled cutover]

Failure scenarios

Регион и его KMS потеряны: backup bytes существуют, но недоступны. Archive gap не позволяет достичь желаемой точки. Старый primary возвращается после promotion и принимает writes. DNS переключён до проверки ledger invariants и downstream reconciliation.

Recovery protocol

  1. Объявить incident authority и запретить split-brain writes старого региона.
  2. Определить последний проверенный recovery cut и реальные gaps по WAL/source evidence.
  3. Восстановить данные, роли, ключи, contracts и dependencies в изолированном окружении.
  4. Согласовать replay offsets и generations с восстановленной sink DB.
  5. Проверить ledger/reconciliation и способность безопасно принимать новые команды.
  6. Переключить traffic, наблюдать recovery backlog; отдельно планировать failback без двойных writers.

Trade-offs и критерии выбора

Синхронная межрегиональная запись уменьшает отдельные loss windows ценой latency и availability. Асинхронная проще для throughput, но требует business решения о подтверждённых и потерянных операциях. Restore drill дорогостоящ, зато измеряет зависимости, которых нет в backup checklist.

FinTech и iGaming

Для payments необходимо выяснять судьбу externally accepted операций, потерянных в локальном restore. Для игровой аналитики можно восстановить историю из архива позже, но wallet authorization должен иметь отдельный критерий готовности.

Практический пример

Составьте restore drill по backup comparison: начать таймер объявления, восстановить isolated target, записать достигнутый cut, потери и время до checked service. Никакие реальные RPO/RTO в справочнике не измерены. См. storage topic.

Типичные ошибки проектирования

Считать успешную загрузку backup проверкой restore; измерять RTO только временем старта pod; хранить backup и ключи в одном failure domain; failback без fencing.

Вопросы на собеседовании

Может ли реплика быть backup? Она может быть источником backup, но сама mutable copy не даёт защищённой истории.

Почему offsets входят в DR? Несогласованный progress source и restored sink может пропустить данные или повторить эффект.

Дополнительные источники