バックアップとリストア

コントロールプレーンのバックアップは、多くのものより難しい仕事を担います。すなわち、その改ざん検知可能な台帳が証明可能なほど無傷な状態で戻ってこなければなりません。 olivares dr はこの要件を中心に構築されています —— すべてのバンドルはテナントごとのチェーンの先端を記録し、リストアは復元された台帳が連続性安全でない場合に非ゼロで失敗します。 dr drill はスクラッチディレクトリ上の合成台帳で、バックアップからリストアまでの台帳連続性を確認し、測定した RTO を表示します。権限、鍵の保管、リストア時点より後の作用は確認せず、本番のデータディレクトリには触れません。

バンドルはあなたが提供する KEK —— Argon2id 由来のパスフレーズ（--passphrase-file）か、 KMS からの生の 32 バイト鍵（--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 が鍵+マニフェストのコンパニオンバンドルを生成し、これがあなたの WAL アーカイブ PITR セットアップ（deploy/postgres/backup/pitr-setup.md）と組み合わさります。ラッパースクリプト deploy/postgres/backup/pg-dump.sh / pg-restore.sh は同じフローをパッケージ化します。

知っておく価値のある二つの正直さのスイッチ:

バックアップは、バックアップ時に検証されない台帳のキャプチャを拒否します —— --allow-unverified は存在し、ログに記録され、推奨されません。
事前に作成したスナップショット（--snapshot-file/--pitr-ref）を --admin-dsn なしで使う場合、バックアップはキャプチャされたテナント集合が RLS により制限され不完全である可能性を警告します —— ダンプ自体は正しく、admin ロールを必要とするのはマニフェストのテナント横断インベントリです。（pg_dump を直接実行するのは別のケースで、上記のとおり最初の時点で拒否されます。）

スケジューリング: Compose スタックはバックアッププロファイルを、 Helm チャートは CronJobを提供します。ベアメタルでは、上記のコマンドを cron で実行します。表の数値は目標です。 cron のティアでは、RPO の目標は cron の間隔です。dr drill は合成台帳で SQLite の RTO （リストア、起動、検証）を測定します。RPO は測定せず、Postgres のリストアも測定しません。測定された SQLite の RTO は、イベント数とホストとともに docs/DR-RUNBOOK.md にあります。それらはこの表の目標ではありません。

ティア	メカニズム	目標 RPO	目標 RTO
SQLite	cron での `dr backup`	cron の間隔	< 15 min
Postgres logical	cron での `pg-dump.sh`	cron の間隔	< 30 min
Postgres PITR	ベースバックアップ + WAL アーカイブ	≈ 秒単位	< 30 min

バンドルをオフサイトにミラーリングし、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>

リストアのシーケンスは意図的なものです。まず署名鍵（上書きに対してフェイルクローズ —— --force が明示的なオーバーライドです）、次にストアのスナップショット、そして 復元されたストアを起動して台帳の連続性を証明し、チェーンが安全でない場合は非ゼロで終了します。いかなるリストア後も、オフボックスのチェックポイントピンに対して再検証してください —— 復元された古いスナップショットは、単純なウォークは通過しても、オフボックスの比較では失敗することがあります（トラブルシューティング § 台帳）。

すべてを決める二つの鍵

鍵	ルール
DR KEK（パスフレーズまたは生の鍵）	これがなければ、すべてのバンドルはノイズです。バンドルとは別のシステムに保管してください。両方を同時に失うことが障害モードです
`audit-signing.key`（データディレクトリ内）	プロビジョニング時にオフボックスでバックアップしてください —— エンジンは初回起動時に警告するだけで、強制されたエスクローは存在せず、鍵を失うと台帳は恒久的に検証不能になります。公開鍵もオフボックスでピン留めしてください（`GET /v1/audit/pubkey`）

署名鍵そのものの KMS ベースの保管（BYOK エンベロープ、ローテーションの儀式、olivares keys）については CLI リファレンスを、障害モードのウォークスルーについてはトラブルシューティングページを参照してください。