バックアップと復元

このページで解決すること

バックアップの範囲はフォルダの根ひとつと環境設定ファイル一つに収まります。このページでは何をバックアップし、どう取り、どう戻し、戻したあと何を十件確かめれば済んだと言えるかを並べます。バックアップは pg_dump、pg_restore、tar を使います。データベースと OS 自身の道具です。

必要なもの

永続化の置き場所は三つで、いずれも bind mount です。

ホスト側の置き場所	中身
`${DATA_PATH}/postgres`	業務データ全部、監査記録、暗号化した資格情報と鍵の包み
`${DATA_PATH}/recordings`	セッションの録画ファイル
`${DATA_PATH}/audit`	監査の代替書き出しファイルと封印期間のログ

これに .env が加わります。鍵の構成が入っているからです。バックアップは必ず暗号化して保管し、マスター鍵の材料とは別の場所に置きます。 DATA_PATH のディレクトリ権限は 0750 かそれより厳しくすることを勧めます。

書き出した成果物の置き場所とオフサイトの一時領域はバックアップの範囲に入りません。証拠パッケージには独自の保存期間があり、期限で消えます。オフサイトの一時領域の中身は、アップロードが終われば取っておく意味がありません。

手順

内蔵データベースを使うパッケージ導入では custodexa.sh のメニューでバックアップを選ぶか、sudo /opt/custodexa/custodexa.sh backup を実行します。以下の手動手順も内蔵データベースとローカルの postgres ディレクトリを前提とします。外部データベースの構成では、そのデータベース、データファイル、.env、tls/ の整合したバックアップを自分で用意します。エクスポート成果物は ${DATA_PATH}/exports に永続化されますが、標準のバックアップ範囲には入りません。期限を超えて保管するものはダウンロードします。

0. まず変数を取る

どの手順も最初は同じです。.env を文字として読み、source はしません。

ENV_FILE="${ENV_FILE:-./.env}"
env_get() { sed -n "s/^[[:space:]]*$1=//p" "$ENV_FILE" | tail -n 1; }
DATA_PATH="${DATA_PATH:-$(env_get DATA_PATH)}"
DB_USER="${DB_USER:-$(env_get DB_USER)}"
DB_NAME="${DB_NAME:-$(env_get DB_NAME)}"
printf 'DATA_PATH=%s\nDB_USER=%s\nDB_NAME=%s\n' "$DATA_PATH" "$DB_USER" "$DB_NAME"

このあとのコマンドでは必ず "${VAR:?}" の形で参照し、値が無ければその場で失敗するようにします。

1. 停止ありのバックアップ

アップグレード前のバックアップは停止ありにします。順序は、アプリを止める、データベースを取る、ファイルを取る、設定を取る、起動する、です。

docker compose stop backend guacd frontend
pg_dump -Fc でデータベースを書き出す
tar -czf で recordings と audit の二つのディレクトリをまとめる
.env を複製する
docker compose start backend guacd frontend
pg_restore --list と tar -tzf で二つの成果物が読めることを確かめる

2. 停止なしのバックアップ

日常のバックアップは止めずに取れます。停止と起動の二手順を飛ばし、先にデータベースを取ってから録画のディレクトリを複製します。整合性の向きは意図したものです。録画のディレクトリの方がデータベースより新しい状態にします。

復元のしかた

バックアップと違うのは、.env を先に戻し、変数はそのあとで取ることです。

docker compose down
.env を戻す
戻した .env から変数を取る
録画と監査のディレクトリの書庫を展開する（戻す先の postgres のディレクトリは空である必要があります）
データベースのサービスだけ起こし、接続を受けるまで待つ
pg_restore --clean --if-exists でデータベースを戻す
Linux では recordings ディレクトリの所有者とグループを 1000:0、権限を 2770 にしてから、docker compose up -d で全サービスを起こす

復元後に確かめる十項目

サービスがすべて起きていること。
バックエンドのヘルスチェックが通ること。
起動ログに致命的なエラーが無いこと。
フロントエンドが 200 を返すこと。
ログインの経路が使えること。
鍵台帳の四つのフィンガープリントがバックアップのときと同じであること。
暗号化された項目が開けること（資産の編集ページを開き、資格情報がまだ使えることを確かめます）。
録画をひとつ抜き取り、再生できること。
監査チェーンの検証が通ること。
オフサイト保管を使っている構成では、台帳とバケットの突き合わせも行うこと。

オブジェクトストレージのバケットの推奨設定

オフサイト保管のバケットは導入側で管理します。推奨は次のとおりです。

S3 または互換のサービス：バージョニングを有効にします。削除や書き換えを防ぎたい場合はバケットを作るときにオブジェクトロックを有効にします（作ったあとから足せません）。ライフサイクル規則の期限は録画の保持ポリシーに合わせ、現行でないバージョンの期限の規則も足します。アクセス権限は、指定した接頭辞への書き込み、オブジェクトとそのメタデータの読み取り、バケットの構成の読み取りに絞ります。
GCS：バケットの保持ポリシーを基準にし、権限はオブジェクトの作成とオブジェクトの閲覧の水準にします。

監査で見えること

復元後のチェーンの検証の結果は区間ごとに状態を出すので、戻した監査データがまだ自分と整合していることを示せます。
鍵のフィンガープリントの突き合わせは、暗号材料が入れ替わっていないことの直接の証拠です。
オフサイトの台帳は一件ごとにハッシュと保管の連鎖のイベントを記録します。突き合わせの結果は証拠のオフサイト保管を参照してください。