Резервное копирование и восстановление

У резервной копии control plane задача сложнее, чем у большинства: она должна вернуться с доказуемо целостным журналом с обнаружением подделки. olivares dr построен вокруг этого требования — каждый комплект фиксирует вершины цепочки по каждому тенанту, восстановление завершается с ненулевым кодом, если восстановленный журнал небезопасен по непрерывности. dr drill проверяет непрерывность журнала от резервной копии до восстановления на синтетическом журнале во временном каталоге и печатает измеренный RTO. Он не проверяет права, хранение ключей и эффекты после точки восстановления и не трогает каталог данных продакшна.

Комплект шифруется под KEK, который вы предоставляете — парольной фразой, выведенной через Argon2id (--passphrase-file), или сырым 32-байтным ключом из вашего KMS (--kek-key-file); требуется ровно один из них. Ключи подписи аудита и каталога путешествуют запечатанными внутри комплекта.

Зарегистрированный механизм управления восстановлением DR в 26.10 поддерживает PostgreSQL 15, 16, 17 и 18 (измерено на 15.19, 16.15, 17.11 и 18.6). Другие основные версии отклоняются с ошибкой DR restore control contract: PostgreSQL major <major> is unsupported (verified contracts: 15, 16, 17, 18), где <major> — обнаруженная основная версия сервера. Механизм управления никогда не исправляется: после обновления существующей установки до новой основной версии механизм, не соответствующий каталогу и правам новой версии, отклоняется.

Резервное копирование

SQLite (один узел) — безопасно во время работы serve (снимок использует VACUUM INTO; WAL допускает параллельное чтение):

olivares dr backup \
  --data-dir /var/lib/olivares --engine sqlite \
  --out /backups/olivares-dr-$(date -u +%Y%m%dT%H%M%SZ).drbundle \
  --passphrase-file <your-dr-passphrase-file>

Postgres — согласованный pg_dump --format=custom, управляемый той же командой (--engine postgres --dsn … --admin-dsn …), либо передайте готовый дамп через --snapshot-file. Запуск дампа напрямую требует --admin-dsn: pg_dump удерживает row_security=off и аварийно завершается под ролью приложения на таблицах с FORCE ROW LEVEL SECURITY. Поэтому команда отклоняет запуск сразу, а не молча выдаёт пустой результат. Для почти нулевого RPO --pitr-ref создаёт сопутствующий комплект ключей+манифеста, который сочетается с вашей настройкой PITR на основе архивирования WAL (deploy/postgres/backup/pitr-setup.md); скрипты-обёртки deploy/postgres/backup/pg-dump.sh / pg-restore.sh упаковывают тот же процесс.

Два переключателя честности, о которых стоит знать:

• Резервное копирование отказывается захватывать журнал, который не проходит проверку на момент копирования — --allow-unverified существует, логируется и не рекомендуется.
• Резервная копия Postgres без --admin-dsn (выделенной роли NOSUPERUSER BYPASSRLS) предупреждает, что захваченный набор тенантов может быть ограничен RLS и неполон. Это касается случая готового снимка (--snapshot-file / --pitr-ref): сам дамп корректен, а административная роль нужна для межтенантной инвентаризации в манифесте — выделите её для полного покрытия всех тенантов.
• Запуск pg_dump самой командой — другой случай: он не предупреждает, а отклоняется сразу, потому что без --admin-dsn дамп аварийно завершился бы под ролью приложения (см. выше).

Планирование: стек Compose поставляет профиль резервного копирования, Helm-чарт — CronJob; на bare metal поставьте приведённую выше команду в cron. Цифры в таблице — цели. Для уровней с cron цель RPO равна интервалу cron. dr drill измеряет RTO SQLite на синтетическом журнале (восстановление, запуск и проверка). Он не измеряет RPO и не измеряет восстановление Postgres. Измеренные RTO SQLite, с числом событий и хостом, записаны в docs/DR-RUNBOOK.md; это не цели этой таблицы.

Уровень	Механизм	Целевой RPO	Целевой RTO
SQLite	dr backup по cron	интервал cron	< 15 мин
Postgres logical	pg-dump.sh по cron	интервал cron	< 30 мин
Postgres PITR	базовая копия + архивирование WAL	≈ секунды	< 30 мин

Зеркалируйте комплекты вне площадки и держите KEK отдельно от комплектов (3-2-1): резервная копия на том же хосте — это не аварийное восстановление, а комплект, путешествующий вместе со своей парольной фразой, не зашифрован ни в каком значимом смысле.

Учения — до того, как они понадобятся

dr verify проверяет комплект, не обращаясь к вашему каталогу данных. На SQLite он восстанавливает комплект во временный каталог и проверяет непрерывность журнала; при неудаче завершается с ненулевым кодом. На Postgres он проверяет дайджест комплекта и расшифровку ключей. Полная проверка цепочки комплекта Postgres требует восстановления на временный Postgres. Запустите проверку так:

olivares dr verify --in /backups/olivares-dr-<ts>.drbundle \
  --passphrase-file <your-dr-passphrase-file>

dr inspect --in <bundle> печатает манифест (KEK не нужен, секреты не показываются) — какой движок, какие тенанты, какие вершины цепочки. Проводите учения с той же периодичностью, что и резервное копирование; непроверенная резервная копия — это надежда, а не контроль.

Восстановление

olivares dr restore --in /backups/olivares-dr-<ts>.drbundle \
  --data-dir /var/lib/olivares --engine sqlite \
  --passphrase-file <your-dr-passphrase-file>

Последовательность восстановления продумана: сначала ключи подписи (fail-closed при перезаписи — --force это явное переопределение), затем снимок хранилища, затем оно загружает восстановленное хранилище и доказывает непрерывность журнала, завершаясь с ненулевым кодом, если цепочка небезопасна. После любого восстановления повторно сверьтесь со своей внеплощадочной привязкой контрольной точки — восстановленный более старый снимок может пройти наивный обход, но не пройти внеплощадочное сравнение (устранение неполадок § журнал).

Два ключа, которые решают всё

Ключ	Правило
DR KEK (парольная фраза или сырой ключ)	без него каждый комплект — это шум. Храните его в системе, отличной от комплектов; одновременная потеря обоих — это сценарий отказа
audit-signing.key (в каталоге данных)	сделайте его внеплощадочную резервную копию при подготовке — движок только предупреждает при первой загрузке, принудительного эскроу нет, а потерянный ключ делает журнал навсегда непроверяемым. Закрепите открытый ключ вне площадки тоже (GET /v1/audit/pubkey)

Для хранения самих ключей подписи на основе KMS (конверты BYOK, церемонии ротации, olivares keys) см. справочник по CLI; для разборов сценариев отказа — страницу устранения неполадок.