Jellyfinのアプリデータ、キャッシュ、バックアップを分ける方法

Jellyfinのアプリデータ、キャッシュ、バックアップを分けるには、再構築後も保持すべきもの、再生成できるもの、稼働中の状態を保存するデバイスが故障した後も利用できる必要があるものを見極めます。小型サーバーでは、この3つの役割を同じ物理SSDに置くこともできますが、同じライフサイクルや復旧方針を共有させてはいけません。

永続的なアプリケーション状態には、データベース、設定、ユーザーと再生の状態、同じサーバーを再び使えるようにするために必要なその他のファイルが含まれます。キャッシュとトランスコードの作業データは、使用中のタスクがなくなれば破棄できます。バックアップは復旧用のコピーであり、復旧対象と同じストレージ境界に依存しないようにしてください。

アプリの永続データを正式な状態として扱う

まず、Jellyfinの永続状態を保持するホストパスまたはボリュームを特定します。コンテナ環境ではイメージは置き換え可能ですが、コンテナを再作成した後に接続し直す必要があるのは、マウントされた状態データです。ホストパス、コンテナパス、所有者、ファイルシステム、空き容量の下限、バックアップ方法を記録してください。

最新のJellyfinのDocker Compose構成では、メディアをマウントする前に、永続的な設定ディレクトリとキャッシュディレクトリを分けています。最初は両方のディレクトリが同じSSD上にあっても、このパスの区別は運用上役立ちます。

トラブルシューティング時に消去してもよい場所に、正式なデータベースを置かないでください。キャッシュを正常に消去しただけで、ユーザー、ライブラリ、視聴状況、サーバーの識別情報がリセットされるようなことがあってはなりません。

キャッシュとトランスコード用領域は再生成可能な作業データとして扱う

キャッシュは、同じ作業の繰り返しを減らしたり、一時的な処理結果を保持したりするためのものです。価値があるのはパフォーマンスと利便性であり、サーバーの識別情報ではありません。通常のバックグラウンド処理やトランスコードのピークに十分な容量を確保しつつ、サーバー全体を復元しなくても再生成できるようにしましょう。

データベースのバックアップ方針が、大量に書き換わるキャッシュやトランスコードの処理に左右されないようにしましょう。同じ高速デバイスで両方の役割を担う場合は、別々のディレクトリまたはデータセットを使い、それぞれに個別のクォータと監視を設定します。これにより、一時的な急増で空き容量が使い切られ、データベースへの書き込みや将来の復元に必要な容量がなくなるのを防げます。

ブラウジング、メタデータ、状態操作が遅く感じられる一方で、シーケンシャルなメディア読み込みに問題がない場合、ZimaSpaceの操作性に関わるメディアサーバーの状態をSSDに置く分析が、メディアライブラリ全体を同じストレージ負荷とみなさずに次のテストを行ううえで役立ちます。

コンテナは使い捨て、状態と再構築手順は使い捨てではない

コンテナは再取得できますが、デプロイ手順と永続データが再び現れるとは限りません。Composeまたはサービス定義、イメージのバージョンまたはタグの運用方針、マウント構成、サービスID、必要なシークレットの参照情報、永続化されたJellyfinの状態を保存してください。

このDockerボリュームのバックアップ手順における実践的な原則は、有用な復旧データは使い捨てのコンテナ自体ではなく、ボリューム、バインドマウント、アプリデータ、サービス定義にあるということです。

稼働中のデータベースでは、サービスが忙しい間にすべてのバイトをコピーすることより、一貫性が重要です。任意の稼働中ファイルコピーを確実な復旧ポイントとみなすのではなく、アプリケーションがサポートするバックアップ方法か、デプロイ環境に適した制御された停止またはスナップショットの方法を使ってください。

Featured

ZimaCube 2 パーソナルクラウド ホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

稼働中の状態の隣にあるバックアップではホスト障害に対応できない

稼働中のデータベースの隣にあるバックアップは、誤操作による変更には役立ちますが、本番環境を失わせるあらゆるストレージプール、ホスト、ランサムウェア、盗難、停電の事態を乗り越えられるわけではありません。別のデバイスまたは管理境界に復旧用コピーを保管し、それを読み取るために必要な鍵や認証情報も保護してください。

セルフホスティングのバックアップ計画では、状態、シークレット、復旧用コピー、復元手順をまとめて整理する必要があります。このセルフホスティング復旧監査では、スナップショットの数を計画の完全性とみなすのではなく、被害範囲が及びにくい場所へのコピーと、再構築に必要な情報の記録を重視します。

バックアップ先が、稼働中のアプリ用プールと同じキャッシュ保持ルールやクリーンアップコマンドの対象にならないようにしてください。同じ筐体に一時的に保存する場合でも、バックアップは別の役割です。

ドライブを購入・移動する前にストレージの役割を整理する

このマップがあれば、アプリ状態のレイテンシだけが問題なのにすべてを最速のディスクへ移したり、コンテナの再構築に必要なサービス定義を省いて一時ファイルをすべてバックアップしたりする、よくある再設計の誤りを防げます。

使い捨ての復元で分離を証明する

Jellyfinの状態を新しいパスまたは隔離されたホストに復元し、コピーしたデプロイ定義の参照先をその場所に変更します。代表的なメディアに破壊的変更を加えずにアクセスできるようにして、元のキャッシュなしでサービスを起動します。キャッシュが空の状態から始まっても、サーバーには期待どおりのID、ライブラリ、ユーザー、設定が戻ってくるはずです。

バックアップが本番環境の状態を借りずに、隔離された復元先へ復元され、検証されるときにのみ、その違いを測定できます。テスト用のJellyfinインスタンスは復旧用コピーから起動し、必要なパスに再接続して、稼働中のボリュームが密かに復元を補完していないことを証明する必要があります。

キャッシュを削除してもIDが失われず、ライブラリを記憶から再構築せずにランタイムを再作成でき、稼働中のアプリデータ用デバイスが利用できないと想定した後でも、少なくとも1つのバックアップからサービスを復元できるなら、その構成は要件を満たしています。