バックアップとリストア（自らを証明する DR）

コントロールプレーンのバックアップは、多くのものより難しい仕事を担います。すなわち、その改ざん検知可能な台帳が証明可能なほど無傷な状態で戻ってこなければなりません。 olivares dr はこの要件を中心に構築されています —— すべてのバンドルはテナントごとのチェーンの先端を記録し、リストアは復元された台帳が連続性安全でない場合に非ゼロで失敗し、 drill サブコマンドは本番に触れることなくバンドルがリストア可能であることを証明します。

バンドルはあなたが提供する KEK —— Argon2id 由来のパスフレーズ（--passphrase-file）か、 KMS からの生の 32 バイト鍵（--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 が鍵+マニフェストのコンパニオンバンドルを生成し、これがあなたの 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 で実行します。あなたのスケジュールが、そのままあなたの RPO になります。

ティア	メカニズム	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: スクラッチディレクトリでの完全なチェーン検証。安全でない場合は非ゼロで終了します）。

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 リファレンスを、障害モードのウォークスルーについてはトラブルシューティングページを参照してください。