アップグレードとロールバック

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

更新前に停止バックアップと検証済みの旧イメージを残し、更新後にサービスと証拠チェーンを確認します。パッケージ導入では custodexa.sh upgrade を使います。バックアップ手順はバックアップと復元を参照してください。

必要なもの

• 更新前の停止バックアップ、旧版パッケージ、検証済みイメージ ID。
• .env、データディレクトリ、四つの鍵の指紋の記録。
• 既存セッションの終了とデータベース移行に必要な停止時間。

設定のしかた

更新前

新規接続を止め、既存セッションと監査キューの終了を待ちます。内蔵データベースの構成では custodexa.sh backup またはバックアップと復元の手順で停止バックアップを取れます。外部データベースの構成では、そのデータベース、データファイル、.env、tls/ の整合したバックアップを自分で用意します。バージョン、イメージ ID、鍵の指紋、テーブル件数を記録します。DATA_PATH は絶対パスにします。

新版のエクスポート成果物は ${DATA_PATH}/exports に永続化され、標準のバックアップ範囲には入りません。旧版から手動更新する前に必要な成果物をコンテナ外へ移すか、ダウンロードします。

パッケージ導入

インストール済みの custodexa.sh で新版を照会し、メニューで対象を選ぶか、次を実行します。

sudo /opt/custodexa/custodexa.sh upgrade             # 照会のみ
sudo /opt/custodexa/custodexa.sh upgrade 1.14.0      # 対象版
sudo /opt/custodexa/custodexa.sh status

ダウンロード済みパッケージのパスも指定できます。対象のない照会に --images-from は指定できません。インストール済みスクリプトが 1.14.0 以降なら、メニューでイメージソースを選べます。コマンドの --images-from auto|source は省略時に auto です。自動ではホスト、オフラインバンドル、GHCR、Docker Hub、最後にローカルビルドの順に試します。source はパッケージ内のソースを検証して backend と frontend をビルドします。上流イメージとビルド依存関係は別途取得するため、完全なオフライン手段ではありません。取得、検証、ビルドの長い処理は開始前に進捗、完了時に結果を表示します。

1.13.x から初めて 1.14.0 に上げるときは、インストール済みの旧スクリプトが開始します。旧スクリプトは --images-from を受け付けず、メニューにもソース選択がありません。フラグを省くと 1.14.0 側は auto を使います。1.14.0 のインストール後のアップグレードからソースビルドを選べます。スクリプトは停止時間をプレビューし、内蔵データベースをバックアップします。外部データベースは一貫したバックアップを自分で用意します。自動ロールバックはありません。データベース移行の結果はバックエンド起動ログで確認します。

古い git clone 導入の手動移行

古い git clone ツリー内で scripts/custodexa/custodexa.sh を直接実行するか、CUSTODEXA_HOME をそこに向けると、旧版のソース導入であること、導入ファイルとサービスは変更されていないことを説明して操作を拒否します。先にバックアップと導入設定を確認し、アップグレード SOP の手動移行手順に従うか、別の空のディレクトリへパッケージを導入してバックアップと復元に沿って手動復元します。既存データのディレクトリで install を直接実行しないでください。

検証とロールバック

ヘルスチェック、鍵の指紋、チェックポイントチェーン、古い録画の再生、新しい接続の監査を確認します。戻す場合はサービスを止め、旧パッケージと検証済みイメージを使い、更新前のデータベース、.env、録画、監査ディレクトリを復元して再検証します。データベース移行は逆向きに実行しません。

監査で見えること

チェックポイント検証と新旧セッションで証拠チェーンを確認できます。テキストセッションの事実の出どころは録画で、エコーされない入力はコマンド本文の記録に残りません。クエリコンソールの構造化された文の記録は、そのクエリの事実の出どころです。