Jellyfinのデータパスを解説：永続化が必要なものと再構築できるもの

データベースの状態、設定、メタデータ、キャッシュ、一時トランスコードファイル、メディアを異なるデータ役割として扱うと、Jellyfinはより安全に運用できます。

すべてのディレクトリに同じストレージ階層やバックアップポリシーが必要なわけではありません。ユーザーアカウントや視聴状態はランタイムを入れ替えても保持する必要がありますが、キャッシュやトランスコード用の作業領域は通常、再構築できます。また、メディアは別の場所で正本として管理されます。これらの役割をマッピングしておけば、コンテナの更新やディスクのクリーンアップが、意図しないサーバーの初期化につながるのを防げます。データを永続化するかどうかは、ランタイムをクリーンに再構築した後もそのデータを保持する必要があるかどうかで決めましょう。

データベースと設定がサーバーの状態を定義する

データベースと設定には、ユーザー、ライブラリ定義、各種設定、視聴状態など、サーバーの識別に関わるデータが含まれています。これらを失うとメディアファイルが残っていても、サーバー自体は実質的に最初から再構築することになります。

Jellyfinの設定状態には、ユーザーアカウント、ライブラリ設定、視聴履歴、メタデータが含まれます。これらは大量のメディアファイルとは別に保護する必要があります。

この状態は、交換可能なイメージやパッケージの外側にある永続パスへ保存してください。永続的なアプリデータ構成を用意すると、ランタイムを再作成した後も安定した場所へ再接続できます。

メタデータは貴重だが、データベースと同一ではない

アートワークや生成されたメタデータは、元の情報の一部を復元できる場合でも、大規模になると再生成に多くの時間がかかります。復旧の優先度は、手作業による調整や処理がどの程度含まれているかによって異なります。

コンテナデータをSSDに置き、大量のメディアをHDDに残すことで、明確なSSD上のアプリデータとHDD上のメディアの分離を実現できます。これにより、ブラウジング状態に関わるレイテンシーと、大容量メディアのストレージを切り分けられます。

どのバックアップ階層に含めるかを決める前に、メタデータの容量と再構築コストを測定してください。手作業で編集したアセットや再生成が難しいアセットは、使い捨てのキャッシュとは別に扱いましょう。

キャッシュとトランスコード用作業領域には期限モデルを設ける

キャッシュやアクティブなトランスコード出力は、現在の処理を高速化または支援するためのものであり、長期的なサーバーの識別情報を定義するものではありません。これらを無条件に保存すると、バックアップ容量が増え、古くなった一時状態まで復元してしまう可能性があります。

メディアサーバーのストレージ設計では、高頻度で変更される一時的な処理領域には、レイテンシーや耐久性について異なる要件があるため、ローカルキャッシュと永続メディアを分離します。

作業用領域は高速なパスに配置し、空き容量を明示的に監視してください。バックアップ対象から除外する前に、削除後でもサービスがその領域を再作成できることを確認しましょう。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

メディアは独立した正本階層として維持する

ライブラリファイルはローカルディスクやNASに保存できますが、アプリケーションの状態を何桁も上回る容量になることがあります。データベースのポリシーをそのまま適用するのではなく、メディアには独自の冗長化とバックアップ方針が必要です。

容量と変更頻度はデータセットごとに異なるため、アプリケーションの状態と大量のメディアの両方に適した保持モデルは、ほとんどの場合1つでは足りません。

各役割でどのパスを正本とするのかを文書化し、Jellyfinの状態を変更されていないメディアライブラリへ再接続する復元テストを実施してください。明確な役割マップを作成しておけば、将来のストレージ移行における不明点を大幅に減らせます。