Immichのどのデータを永続化すべきか、そしてストレージの役割が重要なのはなぜか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

What Immich Data Must Persist, and Why Do the Storage Roles Matter? - Zima Store Online

Immichの信頼性は、正式なオリジナルデータとアプリケーションの状態を永続化しながら、再生成可能な派生データや一時的な作業データを別のストレージ役割として扱うことにかかっています。

すべてのディレクトリを1つのボリュームに置くこともできますが、再構築後も残す必要があるデータ、再作成できるデータ、バックアップとして独立させるべきデータの違いが分かりにくくなります。この区別は、ディレクトリ名そのものよりも、復旧時間、ストレージの配置、クリーンアップ操作の安全性を左右します。

オリジナルメディアは、代替できないコンテンツの役割を担う

アップロードした写真や動画は、このアプリケーションが守るために存在する家族の思い出です。保存先はデプロイ方法やストレージテンプレートの選択によって変わる場合がありますが、その役割は変わりません。これらはキャッシュではなく元データであり、サムネイルや検索インデックスを再生成しても、失われたデータを復元することはできません。

メディアとデータベースの配置を分けて説明する、現在のセルフホスティング概要は、ストレージを単なる容量の問題ではなく、信頼性設計として捉えるうえで役立ちます。ハードウェアに関する提案は例として扱いつつ、大量のオリジナルデータと稼働中のアプリケーション状態を区別する、より一般的な考え方を維持してください。

コンテナを簡単に再作成できるからといって、ディレクトリをその基準で分類しないでください。コンテナやアプリケーションイメージは交換できますが、それらが参照するマウント済みメディアは交換できない場合があります。クリーンアップや移行を行う前に、正式なオリジナルデータの保存先を特定し、独立したコピーが存在することを確認してください。

PostgreSQLは、関係情報を正式に保持する役割を担う

データベースは、ユーザー、アセット、パス、アルバム、共有、メタデータ、設定、検索関連の状態に関するアプリケーションの認識を保持します。したがって、写真でいっぱいのフォルダーは、復元されたImmichインスタンスと同じものではありません。ファイルシステムとデータベースは、同じライブラリの異なる部分を記述しているからです。

サービスアーキテクチャでは、PostgreSQL、メディアストレージ、バックグラウンド処理を分離することで、この依存関係を明確にしています。この分離により、データベースの遅延が操作性に影響する理由や、メディアだけのバックアップではアプリケーション上のすべての関係を保持できない理由が分かります。

障害時の境界を理解することが重要です。データベースのダンプだけでも、写真のバックアップにはなりません。対応するメディアファイルが想定された論理状態で存在している場合に限り、メタデータや関係を復元できます。両方を保護し、併せてテストしてください。

生成メディアは、ストレージと使いやすさを交換する

サムネイル、プレビュー、互換形式の動画エンコードは、オリジナルデータを何度も処理し直すことなく、ブラウジングや再生を実用的にするために存在します。大量の容量を消費することもありますが、オリジナルデータと必要なアプリケーション状態が残っていれば、多くを再生成できるため、復旧上の価値は異なります。

ストレージ役割の分離を扱ったホームラボの例からは、運用者が稼働中のデータベース処理と大量の写真データを異なる場所に置くことが多い理由が分かります。重要なのは、すべての家庭が同じディスクを必要とするということではありません。生成される高頻度変更データは、オリジナルデータとは異なる性能要件やバックアップ方針を持ち得るということです。

再生成可能だからといって、コストがかからないわけではありません。大規模な家族写真ライブラリの派生データを再構築すると、CPU、ストレージI/O、キューの待ち時間を何時間、場合によっては何日も消費することがあります。これらをバックアップから除外するのは復旧時間に関する判断であり、運用上価値がないという証明ではありません。

-15% OFF

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

Single board computer zimaboard2

キューとキャッシュは、信頼できる永続的な情報源ではない

キューの状態やキャッシュは、稼働中のシステムが処理を調整し高速化するのに役立ちます。しかし、代替できない事実をそこだけに保存してはいけません。再起動後に一時的なキューが消えても、永続化されたデータベースとファイルシステムの状態から、アプリケーションが次に何をすべきか判断できる必要があります。

ZimaSpaceのImmichのデータパスに関する記事は、永続的な状態と、システム内でリクエストを処理するサービスを分けて考えるのに役立ちます。キューは処理中の作業を示すものであり、家庭の写真アーカイブそのものと取り違えてはいけません。

カスタム連携が一時パス、バックアップされていないコンテナレイヤー、文書化されていないサイドカーの保存先に固有の状態だけを保存している場合、このモデルは安全ではなくなります。デフォルトの永続化カテゴリですべてのデプロイがカバーされると考える前に、カスタムマウントと上書き設定を確認してください。

ストレージを移動する前に、復旧マトリックスを作成する

オリジナルデータ、プロフィール、データベース、生成されたサムネイル、エンコード済み動画、モデルキャッシュ、バックアップ、設定、外部ライブラリなど、各役割を一覧にします。それぞれについて、ホスト上のパス、正式なデータかどうか、再生成可能かどうか、許容できる最大損失、想定復旧時間を記録してください。

ZimaSpaceの家族写真バックアップガイドは、適切な運用上の境界を示しています。利用可能な家族向けサービスには、保護されたメディアと、障害後にそのメディアを整合した状態で扱うために必要なアプリケーション状態の両方が必要です。

新しいホスト上で代表的なオリジナルデータ、アカウント、関係情報を復元し、その後、意図的に除外した派生データを再生成できることを確認してから、永続化設計を受け入れてください。文書化されていないボリュームを思い出したり、コンテナの書き込み可能レイヤーを復旧したりすることに頼る必要があるなら、ストレージの役割はまだ安全に定義されていません。