互換性のないリリース後にImmichを安全にロールバックする方法
現在の状態を保持し、新しいリリースによってデータベースや設定が変更され、古いイメージでは読み取れなくなっていないかを確認してから、Immich をロールバックしてください。
コンテナイメージは置き換えられますが、永続化された状態はすでに移行されている可能性があります。アップグレードがうまくいかなかった場合は、自動更新と新しい書き込みを停止し、両方のバージョンを記録して、現在のデータベースとメディアを保護します。そのうえで、単純なイメージのロールバックにするか、アップグレード前の復旧ポイントを復元するかを選択します。
状態がさらに変更される前に、失敗したアップグレードを凍結する
証拠を収集する間、自動イメージ更新を無効にし、クライアントから新しい写真が追加されないようにします。古い Immich イメージと新しい Immich イメージの正確なバージョンまたはダイジェスト、PostgreSQL のバージョン、Compose ファイルと環境ファイル、マウントパス、最初に発生した起動エラーまたは移行エラーを記録します。
ZimaSpace のコンテナのロールバック境界に関するガイドでは、重要な違いが説明されています。永続ボリュームはイメージを置き換えても保持されますが、これは古いアプリケーションがボリューム内の状態と互換性を保っている場合に限り安全です。
データベースを読み取れる場合は、失敗した現在の状態をデータベースネイティブの方法でバックアップし、アップグレード前のバックアップとは別に保存します。繰り返しの実験でどちらかを上書きしないでください。すぐに古いバージョンへ戻すことが目的でも、現在のコピーが後で前進するために必要になる可能性があります。
リリースがデータベース移行の境界を越えたか確認する
アップグレード後に最初に発生した障害を調べ、それがデータベース移行の前または途中で発生したのか、移行後のアプリケーション起動時に発生したのか、それともユーザーワークフロー中だけに発生したのかを特定します。このタイミングによってロールバック計画は変わります。新しいリリースによってすでに変更されたスキーマを、古いイメージが理解できない可能性があるためです。
サービスがアップグレード経路の後に失敗した最近の Immich の報告は、サポートされていない、または一部を飛ばした移行経路によって、単純なバージョンの入れ替えが信頼できなくなる理由を示しています。このスレッドは事例研究として扱い、使用しているバージョンにおける正確な移行手順を確認してください。
新しいアプリケーションがデータベースに一切変更を加えておらず、障害がイメージまたはランタイムの互換性に限られる場合は、イメージを固定してロールバックするだけで十分なことがあります。移行が完了している場合は、明確な互換性の根拠がない限り、古いイメージにはアップグレード前のデータベースバックアップを組み合わせるほうが安全だと考えてください。
異なる時期の状態を混在させず、互換性のあるデータベースとランタイムを復元する
最後に正常動作していたアプリケーションバージョン、それに対応するデプロイ設定、互換性のない変更が行われる前のデータベース復旧ポイントを使って、ロールバック対象を構築します。リリースによってメディアファイルが変更されたことが文書化されていない限り、メディアツリーはそのまま保持してください。アプリケーションイメージが変わっただけで、数テラバイトのデータを再コピーする必要はありません。
データベース互換のロールバック計画に関する議論では、スキーマを理解できなくなった古いコードを新しいスキーマに対してデプロイする一般的な危険性が説明されています。コンテナ自体が正常に起動するかどうかよりも、この原則のほうが重要です。
検証が完了するまでモバイルクライアントやスケジュール済みジョブが書き込めないよう、ロールバック用インスタンスを分離して起動します。古いバージョンがすぐにスキーマエラーを報告した場合は停止してください。テスト済みのバージョン固有の復旧手順がない限り、唯一のデータベースコピーに対して手動で移行を逆戻りさせようとしないでください。
正確な正常バージョンのイメージを固定し、その設定を再現する
変更されるタグではなく、特定のバージョンまたは不変のイメージ参照を使用します。最後に正常動作していたデプロイから、対応する環境、サービス依存関係、デバイスマッピング、ネットワーク、ポート、リバースプロキシの転送先を復元します。複数のインフラ層を気付かないうちに変更するロールバックは、別のインシデントを引き起こします。
失敗した新しいイメージと設定は、ロールバックの記録とともに保持します。これにより、互換性の問題を理解した後で、制御された前方復旧が可能になります。新しく作成された成果物をすぐにすべて削除すると、失敗した状態と動作する状態を比較したり、テスト環境でアップグレードを再現したりすることが難しくなる可能性があります。
復元した状態に対して古いサービスが起動した場合も、クライアントを有効にする前にログを確認します。予期しない移行の試行、新規インストールの初期化、ストレージマウントの欠落、権限の書き換えがないことを確認してください。ログインページが表示されただけでは、意図したデータを使用してロールバックされている証拠にはなりません。
元のトリガーのもとで古いバージョンを検証し、前進できる道を残す
代表的なユーザー、古いアセットと最近のアセット、アルバム、共有、検索、管理下での新規アップロードを1件、バックグラウンドジョブ、データベースバックアップの作成、リバースプロキシの経路をテストします。スタックを一度再起動し、同じマウントとデータベースが手動操作なしで戻ることを確認します。
これらの確認に合格するまで新しいアップロードを停止し、その後アクセスを再開して通常の負荷がかかる時間帯を監視します。互換性の問題を理解した後、分離したコピーでアップグレードを再試行できるよう、アップグレード前のバックアップと、失敗した新しい状態のバックアップの両方を保持してください。
古いバージョンがスキーマの非互換性を報告した場合、既知のデータが欠落している場合、または書き込みが予期しないパスに行われている場合、ロールバックは失敗しています。修復を重ねるのではなく、停止して保存済みの復旧ポイントをもう一度復元してください。正確なバージョン、移行ログ、データベースバックアップのタイムスタンプ、Compose の差分、最初に失敗した検証手順を添えてエスカレーションします。
おすすめ商品
サポートとヒント
もっと読む
同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。
Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。
データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。
