Immichは、マウント、権限、レイテンシー、障害時の挙動が適切に設計・テストされていれば、メディア用または外部ライブラリ用のネットワーク共有を安定して利用できます。ただし、PostgreSQLのデータディレクトリは、一般的なSMBまたはNFS共有ではなく、サポート対象の低レイテンシーストレージに置くべきです。
「データ」という言葉には異なるワークロードが含まれます。オリジナルは大容量で永続性が必要なファイル、サムネイルは小規模な操作が多数発生するデータ、外部ライブラリは読み取り専用の場合があり、PostgreSQLにはデータベース向けのファイルシステムセマンティクスが必要です。パスごとに配置を決め、コンテナの起動前に共有をマウントし、空のローカルディレクトリがNASになりすますことを防ぎ、ホストの再起動と制御された共有の中断の両方で動作を検証してください。
移動する前にImmichの各パスを分類する
アップロードライブラリ、サムネイルまたはエンコード済みメディア、外部ライブラリ、データベースディレクトリ、モデルキャッシュ、バックアップを個別に一覧化します。各パスへの書き込み主体と、失われた場合の影響を記録します。メディア共有は適している可能性がありますが、すべてのボリュームを交換可能なものとして扱うと、設計上の合格基準を満たせません。
実用的なNFS手順では、共有ストレージからImmichの外部ライブラリをマッピングする方法が示されています。その外部ライブラリのマウントパターンは、パスと権限の計画には役立ちますが、データベースでNFSを使うべき根拠にはなりません。
PostgreSQLはデータベース向けに推奨されるストレージに置き、ネイティブダンプとバックアップで保護します。ローカルのアクティブストレージに余裕がない場合は、容量を大きく消費するメディアパスだけを、測定結果に基づいて移動し、アプリケーション状態全体を移動するのではなく、その境界を文書化してください。
リモートマウントの順序を確実にする
ホスト上で、明示的な認証情報またはエクスポートルール、安定したアドレス、意図した読み書きモードを指定して共有をマウントします。Immichを起動する前に、想定したファイルシステムであることと、既知のマーカーファイルを確認します。すでにマウント済みのホストパスをコンテナにバインドします。
サービスマネージャーを設定し、Immichがリモートマウントを待機し、空の代替ディレクトリを使って起動しないようにします。マーカーがコンテナ内から見え、テストファイルに想定した所有者が設定された場合のみ、起動は合格です。空のディレクトリやroot所有のファイルが確認された場合は、直ちに停止してください。
共有を利用できる状態で一度、さらにメンテナンス時間帯に共有を意図的に利用できない状態で一度、再起動します。1回目のテストは、Immichの起動前にマーカーが表示された場合のみ合格です。2回目は、Immichが明確に停止または失敗し、裸のローカルマウントポイントへの書き込みを行わない場合のみ合格です。
コンテナの識別情報と共有権限を検証する
サーバー、クライアント、コンテナ間で数値ユーザーIDとグループIDを一致させ、専用の使い捨てフォルダーで作成、名前変更、読み取り、削除をテストします。家族のライブラリを公開するような、全体への書き込み権限で不一致を解決してはいけません。
使い捨てファイルのテストを、ホストだけでなくImmichサーバーコンテナ内からも繰り返します。NAS側で意図した数値所有者が確認できること、およびコンテナを再作成した後もImmichがファイルを再び開けることを確認します。ホスト上だけで成功しても、コンテナ内のパスが正しいことの証明にはなりません。
識別情報または作成・名前変更の挙動が異なる場合は、停止して、限定的なエクスポート、マウント、またはコンテナのマッピングを修正します。実際のライブラリをスキャンする前に再テストしてください。広範な権限変更は不一致を隠す一方で、家族の写真全体を無関係なサービスに公開する可能性があります。
レイテンシーを測定し、共有の中断をテストする
代表的なアップロード、サムネイル生成、タイムラインの閲覧、オリジナルのダウンロード、外部ライブラリのスキャンを実行しながら、サーバーのレイテンシーとジョブの進行状況を測定します。合格条件は、操作に許容できる応答性があり、キューが継続的に増加しないことです。リンク速度だけでは、メタデータ処理の性能を証明できません。
Immichの課題では、不安定なNFSを使用した環境で、データベースとファイルの不整合が報告されています。この限定的なNFS障害事例は、書き込み中の切断を復旧上のリスクとして扱うべきことを示していますが、NFSが常にImmichを破損させるという意味ではありません。
バックアップが完了したメンテナンス時間帯に、重要でないテストを実行している間、メディア共有を中断します。Immichは、裸のマウントポイントへの書き込みを行うのではなく、明確に失敗するべきです。共有を復旧し、テストアセットとデータベースレコードが再起動ループなしに整合することを確認します。
再起動テスト後に導入可否を決定する
コンテナとホストを個別に再起動します。正しい共有が最初にマウントされること、以前のオリジナルと新しいオリジナルを開けること、外部スキャンでアセットが重複しないこと、さらに新しいアップロード1件が再度の再起動後も維持されることを確認します。ZimaSpaceのDASとNASの比較では、レイテンシーと障害ドメインのトレードオフが説明されています。
これらのテストに合格し、共有の不在、レイテンシー、空き容量、inode使用量を監視して警告できる場合は、共有を使用します。ネットワークまたはNASが必要な可用性を満たせない場合、あるいはフェイルオープンなマウント動作を防げない場合は、ローカルストレージまたは直接接続ストレージを選択してください。
Immichが空の状態で起動する、root所有のファイルを作成する、または中断後にファイル欠落エラーを生成する場合は、以前のローカルパスに戻します。プロトコル、マウントオプション、識別情報、パスマッピング、レイテンシー、起動順序を添えてエスカレーションしてください。信頼できるオリジナルとデータベース状態が確認できるまで、破壊的な再スキャンは決して行わないでください。
サポートとヒント
もっと読む

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

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

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

