コンテナの更新に失敗した後にImmichを復旧するには、まず現在の状態を証拠として凍結し、すべてのImmichサービスを最後に正常動作したリリースへ固定します。調整されたロールバックでスタックを起動できない場合にのみ、データを復元してください。
更新によって、アプリケーションコード、データベーススキーマの想定、環境変数、関連サービスのバージョンが一度に変わることがあります。latestを繰り返し取得したり、新旧のコンテナを混在させたりすると、復旧の境界が分かりにくくなります。作業前にComposeファイル、環境設定、ログ、データベース、アップロード先のパスを保存し、その後、イメージのロールバックと、データベースおよびライブラリ全体の復元のどちらを行うか選択します。
失敗した状態を凍結し、更新の境界を特定する
自動再起動を停止し、サーバー、機械学習、データベース、キャッシュサービスの正確なイメージまたはダイジェストを記録します。次の取得を行う前に、起動ログとデプロイファイルを保存してください。成功条件は、何が変わったのかを説明できることです。失敗した場合は、デプロイ履歴またはローカルイメージから旧バージョンを特定できるまで復旧を中断します。
サーバーがデータベースへの接続前に終了するのか、マイグレーション中に終了するのか、準備完了後に終了するのかを確認します。依存サービスへの接続エラーは、ネットワーク、認証情報、またはヘルスチェックの修正が必要であることを示します。マイグレーションエラーの場合は、データベースがすでに変更されている可能性があるため、アプリイメージだけを復元するリスクが高まります。
バージョン指定によるImmichの更新の手順では、リリースの境界とデプロイファイルが重要である理由を説明しています。移行内容の一覧化に役立ててください。ただし、ロールバックの判断では、自分のログとバックアップを最優先します。
まず最後に正常動作したイメージへの完全なロールバックを試す
Immichのすべてのアプリケーションイメージを、以前正常に動作していた正確なリリースに固定します。1つのサービスだけを変更するのは避けてください。永続ボリュームはそのままにして、影響を受けたコンテナを再作成します。スタックが正常になり、ログにスキーマの非互換性が見られなければ、この変更の少ないロールバックは成功です。
旧サーバーが現在のデータベーススキーマを受け入れない場合は停止してください。同じデータベースに対してバージョンを交互に適用したり、マイグレーションテーブルを手動で編集したりしないでください。この失敗は、更新がデータの境界を越えたことを意味します。復旧には、選択したアプリケーションリリースとタイムスタンプが一致するデータベースバックアップを使用する必要があります。
Immich v1.135.3の報告では、更新後に発生した特定のデータベースマイグレーション起動エラーが記録されています。この限定的なマイグレーション例は、最初の致命的なエラーを注意深く読む根拠になります。ただし、その事例のコマンドを別のバージョンにそのままコピーしてよいという意味ではありません。
ロールバックで復旧できない場合にのみデータベースとメディアを復元する
復元を開始する前に、失敗した状態の安全なコピーまたはストレージスナップショットを作成します。クリーンな復旧先を構築し、データベースのバックアップを復元してから、対応するアップロードライブラリと必要なデプロイファイルを公開します。タイムスタンプを合わせるためだけに、現在の唯一のライブラリを古いコピーで上書きしないでください。
データベースのレコードとアセットファイルは、同じコレクションを示していなければなりません。バックアップが最近のアップロードより前のものである場合は、新しいファイルを後で照合できるよう別途保存します。マイグレーションが完了し、想定されるユーザーとアセットが表示され、サンプルとして選んだオリジナルファイルが広範な欠損ファイルエラーなしに開ければ、復元は成功です。
ZimaSpaceのImmich移行ガイドには、永続コンポーネントを移行する際に役立つ一覧が掲載されています。ただし、コンテナイメージそのものを写真ライブラリとみなしてはいけません。
再度更新を試みる前に復旧を検証する
ログイン、タイムラインの閲覧、オリジナルのダウンロード、サムネイル生成、Smart Search、顔認識処理、新しいアップロードを1件、データベースバックアップを1回テストします。コンテナとホストを一度再起動してください。再起動後も同じアセットと機能が利用でき、マイグレーションや権限エラーが繰り返されなければ合格です。
検証が終わるまで、失敗した状態と復旧した状態には別々のラベルを付けて保管します。復旧が旧バージョンに依存する場合は、イメージの自動取得を無効にし、固定したバージョンを記録してください。介在するすべてのリリースを確認し、調整済みの新しいバックアップを取得してから、更新を再試行します。
新しいアップロードが消える、オリジナルファイルが開けない、またはジョブが繰り返しクラッシュする場合は、保存しておいた復旧先へロールバックします。解決しない場合は、移行元と移行先のバージョン、イメージダイジェスト、最初の致命的なログ、データベースバックアップのタイムスタンプ、ストレージの対応関係を添えてエスカレーションしてください。更新の互換性が解決するまでは、最後に正常動作したコピーを決して廃棄しないでください。
サポートとヒント
もっと読む

同時稼働するコンテナ向けに Immich のデータベース接続を最適化する方法
まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。

Immichでジョブやインポートの重複を防ぐ方法
重複するジョブと重複アセットを分離します。正規の取り込み経路を1つに統一し、再試行とパス変更を制御してから、小規模なコホートで再エントリーをテストします。

データベースのボリュームがいっぱいになった後に Immich を修復する方法
空き容量を確保するためにPostgreSQLのWALを削除しないでください。Immichへの書き込みを停止し、データベースの状態を保持したまま安全に容量を追加し、PostgreSQLを復旧してから、再発を防止してください。

