Backup, PITR, RPO и RTO¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Версии в источниках: PostgreSQL 17, MySQL 8.4, Oracle 19c, Cassandra 5.0, Redis 7.4 и ClickHouse 25.8 либо явно названный сервис.

Механизм¶

Backup — восстановимая независимая копия в заданной failure model; PITR восстанавливает состояние к моменту по base+log. RPO задаёт допустимую потерю данных, RTO — допустимое время восстановления сервиса. Это цели, которые проверяются drill, не свойства названия продукта.

flowchart LR
  Backup[Validated base backup] --> Restore[Isolated restore]
  Logs[Continuous retained logs] --> Restore
  Restore --> Validate[Technical and business checks]
  Validate --> Fence[Fence old writer]
  Fence --> Route[Route and reconcile]

Операция чтения или записи по шагам¶

PG base backup + непрерывный WAL → restore isolated target → replay до target time/LSN → проверить consistency → переключить clients. Oracle RMAN/archived redo и MySQL backup/binlog аналогичны по задаче, но форматы/процедуры не взаимозаменяемы. Search snapshots/table metadata требуют своих engines.

Консистентность, отказ и восстановление¶

Сбой WAL archive создаёт gap, который делает позднюю часть PITR недостижимой. Ошибочный DELETE реплицируется; backup в том же административном domain может быть удалён вместе с primary. Encryption keys, credentials recovery, schema/roles/config и catalogs — часть restore.

Выбор, эксплуатация и ограничения¶

RTO включает provisioning, transfer, replay, validation, fencing, routing и прогрев, а не только download. RPO оценивают по фактически доступным logs/replication и acknowledged business operations. Restore одного table может требовать согласования связанных счетов/журналов; физически читаемый файл не доказывает business completeness.

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

Называть replica backup; считать последний успешный backup job доказательством restore. Вопрос: snapshot table format достаточен? Нет, referenced files, catalog и keys могут быть потеряны отдельно.

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

Как доказать применимость механизма? Назвать invariant, scope, isolation/acknowledgement boundary, версию, допустимые interleavings и процедуру восстановления. Один успешный запрос или статическая диаграмма этого не доказывают.

Практические упражнения¶

Напишите runbook потери primary и отдельного logical corruption с неизвестным временем начала. Определите data cut, контрольные суммы ledger и способ reconcile externally acknowledged payments.

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

Политика версий и проверки. Статическая проверка статьи не является runtime/fault verification механизма.