Jellyfinの状態は、アイデンティティ、設定、カタログ、ユーザー履歴という役割ごとに分けて考える必要があります。これらは継続性のために保持すべきですが、多くのキャッシュやトランスコードファイルは再生成できます。
コンテナイメージは置き換え可能ですが、同じライブラリエクスペリエンスを維持するには、そのイメージの外部にあるデータが必要です。生成されたファイルをすべてバックアップするのも非効率です。アーティファクトの中には一時的なものや、簡単に再生成できるものがあるためです。適切な境界線は、状態を失うコストと、それを再構築するコストの比較によって決まります。
アイデンティティと設定がインスタンスを定義する
設定にはサーバーの動作方法が記録され、ユーザー情報と認証状態によって利用者が識別されます。これらのパスを失うと、メディアフォルダーがそのまま残っていても、再構築後に新しいサーバーとして扱われる可能性があります。
永続データの役割についての解説では、アプリケーションディレクトリ全体を1つのバックアップ単位として扱うのではなく、永続データを役割ごとに分けています。
ユーザー、権限、サーバー動作の継続性が重要な場合は、これらの役割を保護してください。
カタログとアートワークでは再構築コストが異なる
データベースには、アイテム、パス、シーズン、人物、再生状態の対応関係が記録されます。一方、アートワークなどの生成アセットは大容量になることがありますが、同じ程度に代替不可能とは限りません。カタログは再スキャンできることが多いものの、所要時間やプロバイダーへの依存を考えると、復元したほうがよい場合があります。
データベース配置モデルを使用して、アプリケーション状態のレイテンシーと整合性を、大容量のメディアファイルから切り分けて考えましょう。
復元するかどうかの判断は、ファイルを技術的に再生成できるかどうかだけでなく、継続性と再構築にかかる時間を基準に行います。
キャッシュとトランスコード用の一時領域は通常、再構築できる
ファイルシステムキャッシュ、サムネイルの作業ファイル、ログ、一時的なトランスコードセグメントは、サーバーの永続的なアイデンティティではなく、現在のアクティビティを示すものです。診断や高速なウォームアップに役立つ場合はありますが、これらをコピーすることは、サービスを保護することと同じではありません。
コールドとウォームのベンチマークでは、コールド時とウォーム時の動作を、永続的な容量とは分けて測定すべき理由が示されています。
バックアップポリシーでは、一部の一時的なパスを除外しながら、ユーザー、設定、カタログの動作を復元するために必要な状態を保持できます。
保持するか再生成するかを表にまとめる
各パスについて、アイデンティティに不可欠か、設定に不可欠か、カタログに不可欠か、生成データか、一時データかを記録します。復元元、想定される再構築時間、失った場合の影響も追加してください。
永続データの役割の記事は、役割ごとの比較に役立ちます。ただし、実際に使用しているプラグイン、プロバイダー、ライブラリの規模を表に反映させる必要があります。
復旧コストが許容範囲内で、そのパスに関連する永続的な依存関係がすでに保護されている場合は、そのパスのバックアップを停止できます。
テック&AIハブ
もっと読む

ローカルAIゲートウェイは、GPUの割り当て前に厳格なコンテキスト上限を適用できますか?
ハードコンテキストゲートの仕組みを優先した説明、その共有リソースに関するトレードオフ、クエリファンアウトに関する3つのよくある質問、そして実践的な検証プロトコル。

ホームAIサーバーは、2.5GbE経由でリモートNASのモデル重みをメモリマップできますか?
リモートNASモデルのメモリマッピングに関するメカニズム重視の説明、共有リソースのトレードオフ、クエリのファンアウトに関する3つのFAQ、そして実践的な検証手順。

複数のコンテナで1つの内蔵GPUを共有しても、ワークロードが漏洩することはない?
共有iGPUコンテナ分離のメカニズムを第一にした説明、共有リソースのトレードオフ、クエリファンアウトに関する3つのFAQ、そして実践的な検証手順。

