.env・設定の上書きファイル・.key.yaml ファイル・compose.override.yaml は、まとめて保護された場所に保管してください。アップロードファイルに外部バケットを使っている場合は、そのバケットも別途バックアップしてください。
バックアップを作成して確認する
pg サービスが動いている間にスクリプトを実行し、その出力をホストの外にコピーしてください。
tar tzf backups/mirobody-uploads-YYYYMMDD-HHMMSS.tar.gz でアーカイブを確認してください。外部バケットには、それ専用の復元演習が必要です。
完全な演習には、保護された隔離のテストホストを使ってください。バックアップと一緒に記録したコードのバージョンをクローンし、公開アクセスのない新しいサーバーデプロイとして設定し、バックアップと対応するキー・設定をコピーします。空のスタックを起動し、アップロードアーカイブまたは外部バケットの復元も含めて、そのテストホストでデプロイを復旧するを実行してください。ログインし、復元された代表的な記録とアップロードファイルを開き、health レスポンスを確認してください。本番のボリュームとネットワークはこのテストに使わないでください。上記の一時データベース確認はより速いアーカイブ確認であり、この完全な演習の代わりにはなりません。
デプロイを復旧する
アプリケーションの書き込みを止めますが、Postgres は動かしたままにしてください。例のダンプ名は、選んだバックアップに置き換えてください。holistic_db_restored がすでに存在する場合は、別の名前を選んでください。Compose とアプリケーションの両方が復元後のデータベースを選ぶよう、.env に PG_DBNAME=holistic_db_restored を設定してください。アプリを起動する前に、対応する暗号化キーと設定を復元してください。新しく生成したキーでは、暗号化された記録を読めません。
ファイルをローカルに保存していた場合は、docker volume ls で実際のアップロードボリューム名を確認してください。mirobody という名前のチェックアウトなら、通常は mirobody_mirobody_upload です。復元前に、その名前のボリュームがすでに存在することを確認してください。存在しないと docker run -v が黙って空のボリュームを作成してしまいます。対応するアーカイブをそのボリュームに復元します。
.env、暗号化キーが復元したデータと一致することを確認してから、アプリを起動してください。