安全なImmich移行は、何を確実に引き継ぐ必要があるかをコピー前に確認することから始まります。写真ファイル、データベース、そして新しいホスト上でそれらを再接続するデプロイ設定です。
ホームサーバーでは、これらの要素を別々のタイミングで移動したり、移行先を誤ったパスで起動したりすることが、移行リスクの主な原因になります。旧サーバーをロールバック用コピーとして扱い、避けられる書き込みを停止し、現在のバージョンとストレージのマッピングを記録してから、検証済みのデータ一式を新しいマシンへ移行してください。以下のチェックリストでは、新しいインスタンスでログインでき、元のライブラリを認識し、ジョブを処理し、空の状態に戻ることなく再起動できるようになるまで、作業を可逆的に保ちます。
ソースを凍結し、正常な状態を記録する
作業は新しいサーバーではなく、稼働中のサーバーから始めます。Immichのバージョン、Composeまたはアプリストアの定義、データベースとストレージのパスを制御する環境変数、写真ライブラリの場所、データベースの場所、外部ライブラリのマウントを記録してください。また、現在のサーバーURLと、検証に使用するユーザーアカウントも記録します。
この棚卸しの目的は、移行がいつの間にかアップグレード、パスの再設計、ネットワーク変更を同時に行う作業へ変わってしまうのを防ぐことです。復元が正常に確認できるまでは、アプリケーションのバージョンと論理的なストレージ構成をできるだけ維持してください。バージョン変更は、移行先が正常に動作することを確認した後に行えます。
コピーする前に、家庭内で許容できるなら新しいアップロードを停止または一時停止します。難しい場合は切り替え時間帯を決め、最後に短時間の同期を行う計画を立ててください。この段階の完了条件は、オリジナルがどこに保存され、データベースの状態がどこにあり、同じ関係性を再現する設定がどれかを確認できる、文書化されたソースマップです。
データベース、アセット、設定を1つの移行セットとして取得する
データベースとメディアファイルは、独立した2つのバックアップではなく、1つの復旧セットとして扱ってください。現在のImmichのデータベースバックアップにはメタデータとファイル参照が含まれますが、写真や動画そのものは含まれません。そのため、データベースのバックアップは、UPLOAD_LOCATIONの対応する内容や、別途管理している外部ライブラリのデータと一緒に移行する必要があります。
使用可能な移行セットには、アセット、PostgreSQLの状態、それらを再接続する設定が必要です。完全なImmichバックアップセットには、アップロード済みアセット、サポート対象のデータベースバックアップ、デプロイ設定が含まれ、復元テストによってセットが機能することを確認します。移行先を1つの復旧ポイントに対応させられるよう、これらをまとめて保管してください。
移行先に触れる前に、移行セットを検証します。データベースダンプが空でないことを確認し、コピーしたライブラリから複数のオリジナルファイルを無作為に選んで確認し、Composeファイルと環境ファイルを同じ移行フォルダーまたはドキュメント一式に保存してください。いずれかの構成要素を検証できない場合は、ここで停止し、新しいサーバー上で補おうとせず、新しいコピーを作成します。
競合する状態を作らずに新しいホストを準備する
まず移行先のディレクトリとマウントを作成し、新しいホストが、使用する予定の正確なパスで意図したディスクまたはネットワーク共有を認識していることを確認します。NASのマウントに失敗すると、通常の空ディレクトリが代わりに残ることがあり、コンテナはそのフォールバックパスを使って問題なく初期化されてしまいます。
ランタイムをインストールしてデプロイ定義を再作成します。ただし、旧サーバーの状態を復元する前に、空のImmichインスタンスへアップロードや設定を蓄積させないでください。移行計画に管理されたパス変更が明示的に含まれていない限り、認証情報、データベース名、ストレージ変数、外部ライブラリのマウント先はソースと一致させます。
新しいサーバーでホスト側のパスを変更する必要がある場合は、コンテナから見えるパスとデータベースの前提が矛盾しないよう、意図的にマッピングしてください。完全なアプリケーションを起動する前に、実効的なマウントがコピー済みデータの場所を指し、すべてのパス変換を説明できる状態になって初めて、移行先の準備が整います。
状態を復元し、すべてのストレージパスを再接続する
バックアップを作成したImmichのバージョンに適した復旧手順を使ってデータベースを復元し、データベースの準備が整ってから残りのサービスを起動します。新しいインストールで異なる復元手順が使われている場合、古いガイドにある破壊的なデータベースコマンドを推測で実行しないでください。
切り替え中は、通常の利用を再開する前にデータベースとストレージの関係を維持してください。検証済みのImmich移行手順も同じ原則に従っています。アプリケーションは、復元されたデータベースの状態と意図したメディアパスに対して開くべきであり、新しいライブラリを初期化して最初から再構築させるべきではありません。
起動後は、負荷の高いバックグラウンドジョブを開始する前にストレージへのアクセスを確認します。異なる日付の古いアセットを複数開き、サムネイルが読み込まれることを確認し、移行前から存在していたアルバムや人物、検索結果を確認してください。外部ライブラリを使用している場合は、それらが読み取り可能であることも確認します。初回セットアップ画面や空のタイムラインが表示された場合は停止し、書き込みによって新しい状態を作成する前に、データベースとマウントのマッピングを再確認してください。
旧サーバーを廃止する前に元のワークロードを検証する
最初のログインに成功しても、移行は完了ではありません。通常のクライアントから使い捨て用のテスト写真を1枚アップロードし、想定したホスト側ストレージに表示されることを確認してから、Immichで削除し、ライブラリが正常なままであることを確認します。これにより、古いデータが読み取れることだけでなく、書き込み経路全体を確認できます。
新しいホームサーバーを再起動し、家庭で重要な確認を繰り返します。ブラウザーからのログイン、モバイルバックアップの接続、複数の古い写真、検索、代表的な動画、ジョブキュー、通常の構成に含まれる場合はリモートアクセスも確認してください。ホストの再起動後も同じ状態が維持され、Immichの起動前にストレージがマウントされることを確認して初めて、移行は完了です。
旧サーバーはすぐに消去せず、電源を切ったまま変更せずに、ロールバック期間を設けて保管してください。新しいインスタンスが予期しない空のフォルダーへ書き込み始めた場合、再起動後に以前のライブラリを再現できない場合、または原因を説明できないデータベースエラーが表示された場合は、新しいアップロードを停止し、移行セットを比較しながら正常な状態のソースへ戻します。移行先が通常利用と新しいバックアップのテストに合格してから、旧ホストを廃止してください。
サポートとヒント
もっと読む

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

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

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

