Immichの状態とは何か、どの部分を永続化すべきか？

エヴァ・ウォン

IceWhale author

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

What Is Immich State, and Which Parts Must Persist?

Immichの状態とは、ライブラリが意図した動作を再現するために必要なメディア、データベース、ID情報、設定、派生データを組み合わせたものです。

オリジナルファイルは不可欠ですが、アプリケーション全体ではありません。アルバム、ユーザー、所有権、顔情報、検索用データ、パスマッピング、シークレットによって、それらのファイルがどのように表示され、誰が利用できるかが決まります。これらの中には権威あるデータもあれば、コストをかけて再構築できるものもあります。

オリジナルメディアとデータベースの関係が中核を形成する

オリジナルの写真と動画は、代替できないコンテンツを保持します。データベースは、Immichがそのコンテンツをどのように理解しているかを保持します。これには、ユーザー、所有権、アルバム、アセット識別子、メタデータ、処理関係が含まれます。単にばらばらのファイルを復旧するのではなく、同じ家庭向けサービスを復元することが目的なら、どちらか一方だけでは不完全です。

ZimaSpaceのImmichバックアップガイドでは、包括的な保護にはアップロード済みメディアとデータベースが含まれると説明しています。この区別は、状態を定義するうえで役立ちます。メディアはどのバイトが存在するかを示し、データベースのレコードは、アプリケーションがそれらのバイトをどのように関連付け、表示し、管理するかを示します。

データベースとすべてのオリジナルメディアの場所を、永続的なホストまたはストレージシステムのパスに対応付けます。外部ライブラリが独自のポリシーによって保護されていることを確認してください。内部コンテナのパス名から永続性を推測しないでください。コンテナの削除や再作成後も残る実際のボリュームまたはバインドマウントを確認します。

設定とシークレットがサービス境界を再現する

Compose定義、環境設定、ストレージマッピング、プロキシルール、IDプロバイダーの設定によって、サービスがデータや相互の接続先を見つける方法が決まります。パスワード、署名用情報、API認証情報も安全に保持する必要があります。これらの設定なしにファイルを復元すると、データベースには接続できても、誤ったIDやパスのもとで動作する可能性があります。

Immichのストレージ計画に関する分析では、データベースとサムネイルの配置を、大量のオリジナルデータの保存場所から分けて考えています。ここから得られる設計上の教訓は、1つの論理サービスが複数の物理的な場所にまたがる場合があるということです。そのため、永続化の一覧は1つのプロジェクトディレクトリではなく、すべてのマウントと依存関係を追跡する必要があります。

デプロイ定義からシークレットを削除したうえで、バージョン管理に保存します。シークレットは暗号化バックアップまたはシークレットマネージャーで保管し、復元手順を文書化してください。バインドマウントの所有者と権限を記録します。検証時には、リモートアクセスを公開したり新しいアップロードを受け入れたりする前に、サービスからデータベースへ接続できることと、メディアを読み取れることを確認します。

派生データは再構築できるが、運用上重要である

バージョンや保持されているレコードによっては、サムネイル、エンコード済み動画、一部の機械学習出力を、権威ある入力データから再生成できます。これらをバックアップから除外すれば、バックアップ容量を削減できます。ただし、復元したサーバーが大規模な家族向けライブラリを再構築する間、時間、計算資源、発熱、応答性の低下が発生します。

独立したバックアップガイドでは、必須のアップロードデータ、ライブラリデータ、プロフィールデータと、Immichが再生成できるサムネイルやエンコード済み動画を区別しています。これは派生データが重要でないという意味ではありません。バックアップ容量と、完全に準備された閲覧・再生環境を取り戻すまでの時間のどちらを優先するか、運用担当者が選べるということです。

派生データを除外する前に、代表的な再構築速度を測定してください。影響を受けるアセットの構成を考慮して慎重に見積もり、ストレージへの書き込みとフォアグラウンド処理との競合も含めます。その結果として生じる遅延が復旧目標に違反する場合は、選択した派生データのパスを保護するか、再構築期間に備えて余分な計算資源を確保してください。

-15% OFF

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

Single board computer zimaboard2

コンテナ破棄テストで永続性を証明する

本番環境ではなく、使い捨て可能なデプロイメントのクローンを使用してください。サンプルのオリジナルファイル、テスト用アルバム、アクセス権の異なる2つのアカウント、既知の検索条件1件について、チェックサムを記録します。宣言済みの永続ストレージを保持したまま、クローンのコンテナだけを削除し、保存済みの設定とシークレットからスタックを再作成します。

コミュニティの永続性に関する報告では、想定していたホスト側のデータベースディレクトリが空のままだったため、再起動後にImmichがオンボーディング画面に戻った事例が説明されています。これは、設定されたパスが、書き込みが実際にそこへ到達している証拠ではないことを示す注意例です。主張している実際のライフサイクル操作を経ても、観測可能な状態が保持されなければなりません。

両方のアカウントが復元され、アルバムの所属が一致し、オリジナルのチェックサムが一致し、既知の検索が期待どおりに動作するか、文書化された再構築状態に入ることを確認できた場合にのみ、テストに合格とします。原因不明のリセットが発生した場合は、永続化できていないものがあることを示しています。同じ前提に基づいて構築されたバックアップ自動化に依存する前に、状態マップを更新してください。