Резервное копирование и восстановление (DR, который доказывает сам себя)

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

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

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

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. Ваше расписание и есть ваш RPO:

Уровень	Механизм	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: полная проверка цепочки во временном каталоге; завершается с ненулевым кодом, если небезопасно):

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; для разборов сценариев отказа — страницу устранения неполадок.