Jellyfinの状態を解説:再構築時に必ず保持すべきものと、再作成できるものWinvalid

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

Jellyfinの状態は、アイデンティティ、設定、カタログ、ユーザー履歴という役割ごとに分けて考える必要があります。これらは継続性のために保持すべきですが、多くのキャッシュやトランスコードファイルは再生成できます。

コンテナイメージは置き換え可能ですが、同じライブラリエクスペリエンスを維持するには、そのイメージの外部にあるデータが必要です。生成されたファイルをすべてバックアップするのも非効率です。アーティファクトの中には一時的なものや、簡単に再生成できるものがあるためです。適切な境界線は、状態を失うコストと、それを再構築するコストの比較によって決まります。

アイデンティティと設定がインスタンスを定義する

設定にはサーバーの動作方法が記録され、ユーザー情報と認証状態によって利用者が識別されます。これらのパスを失うと、メディアフォルダーがそのまま残っていても、再構築後に新しいサーバーとして扱われる可能性があります。

永続データの役割についての解説では、アプリケーションディレクトリ全体を1つのバックアップ単位として扱うのではなく、永続データを役割ごとに分けています。

ユーザー、権限、サーバー動作の継続性が重要な場合は、これらの役割を保護してください。

カタログとアートワークでは再構築コストが異なる

データベースには、アイテム、パス、シーズン、人物、再生状態の対応関係が記録されます。一方、アートワークなどの生成アセットは大容量になることがありますが、同じ程度に代替不可能とは限りません。カタログは再スキャンできることが多いものの、所要時間やプロバイダーへの依存を考えると、復元したほうがよい場合があります。

データベース配置モデルを使用して、アプリケーション状態のレイテンシーと整合性を、大容量のメディアファイルから切り分けて考えましょう。

復元するかどうかの判断は、ファイルを技術的に再生成できるかどうかだけでなく、継続性と再構築にかかる時間を基準に行います。

キャッシュとトランスコード用の一時領域は通常、再構築できる

ファイルシステムキャッシュ、サムネイルの作業ファイル、ログ、一時的なトランスコードセグメントは、サーバーの永続的なアイデンティティではなく、現在のアクティビティを示すものです。診断や高速なウォームアップに役立つ場合はありますが、これらをコピーすることは、サービスを保護することと同じではありません。

コールドとウォームのベンチマークでは、コールド時とウォーム時の動作を、永続的な容量とは分けて測定すべき理由が示されています。

バックアップポリシーでは、一部の一時的なパスを除外しながら、ユーザー、設定、カタログの動作を復元するために必要な状態を保持できます。

保持するか再生成するかを表にまとめる

各パスについて、アイデンティティに不可欠か、設定に不可欠か、カタログに不可欠か、生成データか、一時データかを記録します。復元元、想定される再構築時間、失った場合の影響も追加してください。

永続データの役割の記事は、役割ごとの比較に役立ちます。ただし、実際に使用しているプラグイン、プロバイダー、ライブラリの規模を表に反映させる必要があります。

復旧コストが許容範囲内で、そのパスに関連する永続的な依存関係がすでに保護されている場合は、そのパスのバックアップを停止できます。

テック&AIハブ

もっと読む

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.