セルフホスト型フォトライブラリを検索可能な状態に保つために、一緒に復元しなければならないものは何ですか?

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

オリジナル、カタログデータベース、およびパス定義の設定を1つのリカバリユニットとして復元します。

Immich、Lightroom、PhotoPrism、または類似のホームNASライブラリの場合、画像ファイルだけを復元しても開けることはできますが、人物、アルバム、評価、編集、位置情報、検索結果は失われる可能性があります。検索可能なリカバリには、メディアファイルとそれらを説明するデータベースやカタログ、パスをマッピングする設定、そしてその状態を読み取るために必要な秘密情報やアプリケーションのバージョンが整合している必要があります。

検索可能性を単なるオリジナルファイルの開封以上のものとして定義する

写真ライブラリが検索可能であるとは、アプリケーションが各オリジナルをそのデータベースレコード、メタデータ、アルバムの所属、人物の割り当て、パスに結びつけられる状態を指します。JPEGを開けることができるのはファイルの復元が成功したことを示すだけであり、ライブラリの復元を意味しません。

Immichのリカバリに関する議論では、データベースがファイルの場所とライブラリのメタデータを含む一方で、実際の写真はアップロードフォルダに残っていることが示されています。片方だけを復元すると、オリジナルが存在しないサムネイルやレコードが生成される可能性があります。

復元前に必要な結果を明確に書き出してください:オリジナルが開けること、タイムラインの日付が正しいこと、アルバムが表示されること、人物検索が機能すること、編集や評価が戻ること、ユーザーがアクセスを保持すること。その結果がリカバリユニットに含まれるべきコンポーネントを定義します。

オリジナルとカタログを同じ時間境界から復元する

メディアツリーとそのカタログは同じリカバリポイントを表すべきです。新しいデータベースは古いメディアコピーに存在しないファイルを参照することがあり、古いカタログはディスク上に存在する写真を無視することがあります。

Lightroomのリカバリ事例では、まず写真フォルダを復元し、次にインシデント前の一致するカタログバックアップを復元するという2段階の復元が必要でした。編集、評価、人物、アルバムをオリジナルの外部に保存するセルフホスト型ライブラリにも同様の依存関係があります。

メディアバックアップ、データベースダンプ、設定コピーの中で最も近い共通のタイムスタンプを選択してください。共通点がない場合は、孤立したインスタンスに復元し、ユーザーにライブラリを公開する前にギャップを調整してください。

パス、識別子、およびコンポーネントを結合する設定を保持する

カタログが正常でも、復元されたパス、マウント名、ボリューム識別子、またはライブラリルートが保存された参照と異なる場合、資産が欠落しているように見えることがあります。したがって、パスの一貫性はリカバリの一部であり、復元後の見た目の調整作業ではありません。

Lightroomユーザーは、復元されたファイルが同じ名前とフォルダ構造を保持する必要があると報告しています。コンテナアプリの場合は、バインドマウントパス、環境変数、データベースURL、またはストレージルートが同等の役割を果たすことがあります。

Composeファイルやアプリ設定、環境変数、秘密情報、ユーザーID、マウント定義をデータベースの横に復元してください。アプリケーションが期待する識別子を確認するまでは、一括再リンクや再スキャンは行わないでください。

必要な状態と再生成可能な検索資産を分ける

オリジナル、データベースレコード、ユーザーデータ、アルバム関係、編集、設定は通常必須です。サムネイル、キャッシュされたモデル、一部の機械学習埋め込みは再生成可能ですが、それらの処理が完了するまでライブラリは遅いか部分的に検索不能なままである可能性があります。

最新のImmich展開ガイドでは、サーバー、機械学習、バックグラウンドジョブキューの別々のサービスを説明し、組み込みのデータベースバックアップスケジューリングについても言及しています。これらのコンポーネントは、検索や人物認識が目に見えるメディアディレクトリ以上に依存する理由を説明しています。

どの生成資産が再構築可能か、再生成にどれくらい時間がかかるかを文書化してください。再構築に数日間のCPU時間が必要であったり、元のモデル状態を再現できない場合は、技術的にアプリケーションが再作成可能でも、その資産を実用的なリカバリユニットの一部として保護してください。

復元された状態を互換性のあるアプリケーションバージョンに合わせる

カタログやデータベースは、それを作成または移行したアプリケーションバージョンを必要とする場合があります。古いサービスを新しい状態で起動したり、その逆を行うと、メディアが評価される前に失敗することがあります。

写真ライブラリのユーザーはカタログバージョンの非互換性に遭遇しています。展開されたイメージタグ、移行ノート、データベースバージョンを保持し、テスト環境で期待されるアップグレード経路を再現できるようにしてください。

復元されたライブラリはオフラインまたは一時的な名前で起動し、データベースのマイグレーション、ユーザーログイン、パス解決を確認してから、モバイルクライアントやバックグラウンドジョブが復元状態を変更できるようにしてください。

切り替え前に検索、アルバム、人物を検証する

代表的な古い写真と新しい写真、編集済みアイテム、複数ユーザー、共有アルバム、位置情報メタデータ、既知の人物を含む孤立した復元テストを使用してください。期待される結果が既に文書化されているレコードを検索します。

既存のZimaSpaceのImmichファミリー写真バックアッププランは隣接する計画コンテキストを提供しており、この復元テストはそれらのコンポーネントが一緒に戻ることを証明しなければなりません。

オリジナルが開け、カウントが一致し、アルバムと権限が戻り、検索結果が妥当で、新しいアップロードが正しくインデックスされる場合にのみ切り替えを行ってください。テストライブラリが再起動と新しいバックアップに耐えるまで、以前のインスタンスとリカバリファイルは変更しないでください。

サポートとヒント

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.