Immichのキャッシュと一時ストレージを設定する方法

まず永続的なライブラリ状態を、生成された派生データ、再利用可能なモデルキャッシュ、完全に使い捨てのコンテナ一時データから分離して、Immichのキャッシュと一時ストレージを設定します。

サムネイルやエンコード済み動画はImmichで再生成できるためキャッシュのように感じられますが、容量が大きくなり、再構築にもコストがかかる永続的な作業データです。モデルのダウンロードには異なるライフサイクルがあり、ログや書き込み可能レイヤーの一時データがブートディスクを知らないうちに消費してはいけません。役割ごとにストレージを割り当て、クリーンアップと再起動時の動作をテストしてください。

移動する前に各ストレージの役割を分類する

少なくとも4つの分類でインベントリを作成します。オリジナルと必須のアプリケーション状態、生成されたサムネイルとプレビュー、生成されたエンコード済み動画、モデル・ログ・一時的なランタイムデータです。各分類について、現在のパス、サイズ、増加率、バックアップポリシー、再構築コスト、書き込みを行うサービスを記録します。

生成されたサムネイルと動画の増加に関するユーザーレポートは、サムネイルとエンコード済み動画を別々に測定する必要性を示しています。メディアの構成や処理設定によって生成量が変わるため、個別の比率は一律ではありません。

削除すると空き容量が増えるという理由だけで、ディレクトリを「キャッシュ」と呼ばないでください。失われると再生成に数日かかる、アクティブな再生が壊れる、または復旧計画で保持すべき状態が失われる場合、アプリケーションが技術的には再作成できたとしても、明示的な永続ストレージの役割を与えるべきです。

高頻度で変更される生成データを、レイテンシと耐久性に適した場所へ配置する

サムネイルとプレビューはインタラクティブな閲覧に使われ、多数の小さな読み取りが発生することが多い一方、エンコード済み動画ははるかに大きなシーケンシャル容量を消費する可能性があります。高速SSDは派生データの多い処理を改善できますが、移動によって測定済みの待ち時間が解消される場合に限ります。予期せず満杯になる別の小容量ボリュームを作るだけでは意味がありません。

サムネイルストレージの増加に関するZimaSpaceの説明から得られる一般的なストレージ上の教訓は、オリジナルが別の場所にあっても、アクティブなアプリストレージは満杯になり得るということです。Immich固有のパスは異なりますが、実際に書き込みが行われる役割を監視する必要がある点は同じです。

大容量メディアをHDDまたはNASストレージに保持し、派生データをSSDへ移動する場合は、両方の空き容量下限を監視し、再起動後にすべてのマウントを確認してください。高速な派生データ用領域は、通常の増加に対応できる十分な容量があり、障害発生時に権威あるオリジナルの喪失と誤認されない場合にのみ有効です。

モデルキャッシュは意図的に永続化しつつ、再構築可能なものとして扱う

機械学習モデルは推論のためにダウンロードまたは準備され、相当なストレージを消費することがあります。モデルキャッシュを永続化すると、特に回線が遅い環境で不要なダウンロードや起動処理を避けられますが、復旧の優先順位ではデータベースや家族のオリジナル写真と同じものとして扱ってはいけません。

Immichのストレージアーキテクチャに関するコミュニティの議論は、高速なキャッシュ類似データを大容量の写真ストレージから分離する理由を示しています。このような構成はあくまで例として利用し、何かを移動する前に、自分のCompose定義で現在のパスとマウントを確認してください。

モデルキャッシュを失った場合、必要なソースにサービスがアクセスでき、十分なディスク容量がある限り、通常は再作成または再ダウンロードすれば復旧できます。バックアップツールが大容量の再生成可能なキャッシュを誤って貴重なオフサイト容量で保護しないよう、その動作を文書化してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

書き込み可能レイヤー、ログ、一時領域を制限する

コンテナの書き込み可能レイヤーを、永続的な派生データ、一時的なトランスコード、大量のログのための文書化されていない保存場所にしてはいけません。Dockerのディスク使用量とコンテナのマウントを確認し、増加する大きなパスがすべて、意図的に永続化されているか、明確に使い捨てとなっていることを確認します。原因不明の書き込み可能レイヤーの急増は設定上の兆候であり、初期状態では単なるクリーンアップ対象ではありません。

2026年版Docker HQの安全なDockerディスククリーンアップ手順では、プルーニング前の監査と、データベースを含む可能性のあるボリュームの保護が重視されています。ここでも同じ注意を適用し、各ボリュームとレイヤーの所有者が判明するまで、本番のImmichホストで一括クリーンアップコマンドを実行しないでください。

ログローテーションを設定し、一時データ用パスを急激な増加に対応できる余裕のあるストレージへ配置します。また、多数の小さなファイルが作成される場合は、バイト単位の使用量だけでなくinodeも監視してください。一時パスが満杯になった場合の正しい対処は、その役割に上限を設けるか移動することであり、アプリケーションがたまたま起動するまで不明なディレクトリを削除することではありません。

再起動、再構築、空き容量のテストでストレージ変更を検証する

パスを変更した後、古いアセットと最近のアセットを開き、複数のアルバムを閲覧し、動画を再生し、サムネイル処理または機械学習ジョブを1回実行して、管理下にある新しいファイルをアップロードします。書き込みが意図したデバイスに行われ、データベースが読み取り可能なメディアを引き続き参照していることを確認してください。

コンテナを再起動し、その後ホストも再起動します。正常な設定では、すべての役割が自動的に再マウントされ、想定した派生データとモデルキャッシュが保持され、一時データは使い捨てのままとなり、各アクティブなストレージ層に十分な空き容量があることが報告されます。通常のワークロード期間中もストレージを監視し、計画した場所で増加していることを確認してください。

Immichが重複ディレクトリを作成する、アセットが見つからないと報告する、またはマウント失敗によってコンテナレイヤーへ黙って書き込む場合は、パスの変更をロールバックします。マウントマップ、パスごとのサイズ、所有権、ファイルシステムの空き容量、コンテナのディスク使用量、最初に誤った場所へ書き込んだジョブの正確な内容を添えて、問題をエスカレーションしてください。