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

エヴァ・ウォン

IceWhale author

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

How to Separate Jellyfin App Data, Cache, and Backups - Zima Store Online

Jellyfinのアプリデータ、キャッシュ、バックアップを分けるには、再構築後も残す必要があるもの、再生成できるもの、ライブ状態を保存しているデバイスが故障した後も利用可能でなければならないものを確認します。この3つの役割は、小規模サーバーでは1台の物理SSDを共有できますが、同じライフサイクルや復旧ポリシーを共有すべきではありません。

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

永続アプリデータを権威ある状態の役割にする

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

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

トラブルシューティング中に消去してもよい場所へ、権威あるデータベースを置かないでください。キャッシュのクリーンアップが成功した結果、ユーザー、ライブラリ、視聴状態、サーバーIDまでリセットされるような構成は避けるべきです。

キャッシュとトランスコード領域を再構築可能な作業データとして扱う

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

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

閲覧、メタデータ、状態操作が遅い一方で、メディアのシーケンシャル読み取りが正常な場合は、インタラクティブなメディアサーバーの状態をSSDに保持するというZimaSpaceの分析が、バルクメディアライブラリを同じストレージ負荷として扱わずに、次に試すべき有用な手がかりになります。

コンテナは使い捨てだが、状態データと再構築手順はそうではない

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

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

稼働中のデータベースでは、サービスが処理中にある状態で1バイトずつコピーすることよりも、整合性が重要です。任意の稼働中ファイルコピーを確実な復旧ポイントとみなすのではなく、アプリケーションがサポートするバックアップ方法、または環境に適した制御された停止・スナップショット方式を使用してください。

Featured

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

ZimaCube2

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

ライブデータベースの隣にあるバックアップは、誤った変更からの復旧には役立ちますが、本番環境を失わせる可能性があるすべてのプール障害、ホスト障害、ランサムウェア、盗難、停電から守ってくれるわけではありません。別のデバイスまたは管理上分離された境界に復旧用コピーを保管し、それを読み取るために必要な鍵や認証情報も保護してください。

セルフホスティングのバックアップ計画では、状態データ、シークレット、復旧用コピー、復元手順を一体として整理する必要があります。このセルフホスティング復旧監査では、明白な障害範囲の外にコピーを置くことと、スナップショットを完全な計画とみなすのではなく、再構築に必要な入力情報を文書化することが重視されています。

バックアップ先が、ライブアプリプールと同じキャッシュ保持ルールやクリーンアップコマンドによって消費されないようにしてください。一時的に同じ筐体へ保存されている場合でも、バックアップは別の役割です。

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

役割	例	再構築可能か	主なポリシー
永続アプリ状態	データベース、設定、ユーザー情報、視聴状態、プラグインや設定	低コストでは不可	低レイテンシ、空き容量、整合性のあるバックアップ
キャッシュ／一時データ	キャッシュ、トランスコード用作業領域、破棄可能な中間データ	可能	容量、パフォーマンス、範囲を限定したクリーンアップ
バックアップ	バージョン管理された状態コピー、デプロイ手順、復旧メタデータ	不可。復旧元そのもの	独立した障害ドメイン、保持期間、復元テスト
メディア	映画、番組、家族の動画	元データによる	容量と分離された保護ポリシー

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

破棄可能な復元テストで分離を検証する

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

この違いは、バックアップを隔離された対象へ復元し、本番環境の状態を借りずに検証したときに初めて測定可能になります。テスト用Jellyfinインスタンスは復旧用コピーから起動し、必要なパスへ再接続し、ライブボリュームが復元を密かに完了させていないことを確認する必要があります。

キャッシュを削除してもIDが失われず、ランタイムを再作成してもメモリからライブラリを再構築する必要がなく、ライブのアプリデータデバイスが利用できないと仮定した場合でも、少なくとも1つのバックアップからサービスを復元できれば、この構成は合格です。