最新のブログ

まず max_connections を増やさないでください。Immich のセッション数を測定し、すべてのコンテナの需要を合計し、管理用の余裕を確保したうえで、実証されたボトルネックだけを調整してください。

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

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

Immichは、失われたソース元ファイルを黙って再作成すべきではありません。再生成されたファイルの種類と作成者を特定し、作成時の識別情報を修正してください。

まず、どのパスが変更されたかを特定します。管理対象のメディアルートと外部ライブラリのインポートパスでは、移行方法と古いデータの扱いが異なります。

復元したサーバーが実運用下で、識別情報、メディア、関連付け、書き込み、再起動、新たに復旧可能なバックアップを確認できるまで、古いImmichホストはそのまま保持してください。

分割型のImmich構成がうまく機能することはよくあります。データベースと頻繁に生成・使用されるデータにはSSD、オリジナルにはHDDを使い、それぞれのパスに十分な容量を確保してバックアップし、再起動後の動作も確認します。

アップロード完了後も、バックアップによってCPU、機械学習、動画、データベース、ディスクの処理が開始されることがあります。冷却や同時実行数を変更する前に、稼働中のキューに合わせてファン速度を調整してください。