Jellyfin内蔵バックアップとファイルレベルバックアップは、重複しながらも異なる復旧範囲を保護します。内蔵システムはJellyfinのアプリケーションデータを認識し、サーバーをオンラインにしたままアーカイブを作成できます。手動のファイルレベルバックアップでは、より広範な構成状態を取得できますが、稼働中のアプリケーションデータを安全にコピーするには、事前にJellyfinを停止する必要があります。
多くの場合、より良い計画はどちらか一方を選ぶことではありません。頻繁なアプリケーション復旧ポイントには内蔵方式を使い、ホストパス、設定、コンテナ定義、またはサーバー全体のより広い状態を再現する必要がある場合は、停止状態でのファイルレベルまたはファイルシステムレベルの方式を使います。
通常のオンライン復旧ポイントでは内蔵バックアップが有利
現在のJellyfinバックアップシステムでは、サーバーの稼働中にデータベースを保護し、必要に応じてメタデータ、字幕、トリックプレイデータを含めることができます。そのため、通常の再生を意図的に中断せず、スケジュールされた復旧ポイントを作成するのに適しています。
Jellyfinのバックアップドキュメントでは、内蔵バックアップはオンラインで実行できる一方、手動のデータディレクトリバックアップではサーバーを停止する必要があると説明されています。オンライン方式であっても、同じ時間帯にライブラリスキャンが競合しないよう、アクティビティの低い時間に実行するのが最善です。
復旧の目的が「このJellyfinインスタンスを既知のアプリケーション状態に戻す」ことである場合、これが最も有力なデフォルト方式です。
復旧範囲にホストのレイアウトが含まれる場合はファイルレベルバックアップが有利
ファイルレベルのコピーには、永続アプリケーションフォルダー、Composeファイル、環境ファイル、リバースプロキシ設定、サービスユニット、スクリプト、証明書、その他のデプロイ資産を含めることができます。これらはJellyfin専用アーカイブが自動的に把握するものではありません。
この広い範囲は、システムディスクの故障や交換用ホストへの移行に役立ちます。ただし、一貫性が課題になります。通常のファイルコピー ツールは、変化し続けるSQLiteデータベースを認識しないため、稼働中の永続状態をコピーする前にJellyfinを正常に停止してください。
Jellyfinの復旧リスクにつながるストレージレイアウトに関するZimaSpaceのガイドでも、同じ問題が指摘されています。復元したサーバーに必要なパス、マウント、権限、外部依存関係を誰も再現できない場合、バックアップは不完全です。
データベース対応バックアップは、稼働中のSQLiteファイルのコピーとは異なる
SQLiteはデータベースを認識したインターフェースを通じて、一貫性のあるオンラインバックアップをサポートします。しかし、Jellyfinによる変更中に汎用コピー ツールでファイルを読み取っても、同じ保証が自動的に得られるわけではありません。
SQLiteのバックアップAPIは、調整されたデータベース操作を通じて、アクティブなデータベースを一貫性のある保存先へコピーするよう設計されています。そのため、「ファイルはエラーなくコピーできた」というだけでは、稼働中のJellyfinを手動バックアップする根拠として不十分です。
手動方式がrsync、SMBコピー、zip、または汎用ファイルシステムコピーだけである場合は、ストレージスナップショットがアプリケーションの書き込みと連携していない限り、先にJellyfinを停止してください。
利便性を比べる前に範囲を比較する
| 項目 | 内蔵バックアップ | ファイルレベルバックアップ |
|---|---|---|
| サーバーをオンラインのままにできるか | はい。ただしアクティビティが低い状態が望ましい | 通常のコピーではJellyfinを停止 |
| Jellyfinデータベース | 含まれる | 永続パスが正しくコピーされれば含まれる |
| メタデータ/字幕/トリックプレイ | 選択的に対応 | コピーしたパスに含まれていれば含まれる |
| Compose/ホストスクリプト/プロキシ設定 | 自動では含まれない | 含めることができる |
| ホスト交換のワークフロー | Jellyfinの状態には適している | より広範なデプロイ状態に適している |
| 一貫性のリスク | アプリケーションを認識 | 静止状態またはスナップショット方式に依存 |
バックアップを稼働中のJellyfinと同じ障害ドメインの外に保管する
すべてのバックアップが同じ障害のあるファイルシステム内にある場合、どちらの方式でもプールの喪失から保護できません。検証済みのバックアップアーカイブまたは停止状態で作成した復旧用セットを、別のディスク、NAS、またはオフサイトの場所にコピーしてください。
少なくとも1つはアップグレード前の復旧ポイントを保持してください。Jellyfinは新しいリリースの起動時にデータ移行を適用し、一般的なインプレースのダウングレード手段を提供していないためです。
両方を復旧計画に含める場合は、どちらの復元方式もテストしてください。内蔵アーカイブではアプリケーションの復旧を検証でき、ファイルレベルの復旧訓練では、その周囲にある永続パスと権限を環境が再作成できることを検証できます。
よくある質問
内蔵バックアップを使う前にJellyfinを停止すべきですか?
いいえ。内蔵方式はJellyfinの稼働中に動作するよう設計されていますが、アクティビティが低く、アクティブなライブラリスキャンが実行されていない状態が推奨されます。稼働中のJellyfinデータを通常の手動コピーで取得する場合は、サーバーを停止してください。
内蔵バックアップでホストのバックアップを置き換えられますか?
必ずしも置き換えられるとは限りません。Jellyfinのアプリケーション状態は保護できますが、ホスト全体の復旧には、Composeファイル、プロキシ設定、証明書、マウント、権限、スクリプト、その他の外部設定も必要になる場合があります。
製品比較
もっと読む

JellyfinメディアボリュームにはZFS、Btrfs、ext4のどれが適している?
リカバリーモデルに応じてJellyfinのメディアファイルシステムを選択しましょう。プールの整合性を重視するならZFS、LinuxネイティブのCoWならBtrfs、運用の複雑さを抑えるならext4がおすすめです。

KodiとJellyfinの併用 vs スタンドアロンのJellyfinクライアント:どちらが適している?
クライアント側の状態管理を重視するカスタマイズ可能なテレビ中心のワークフローにはKodiを、よりシンプルで複数デバイスに対応したサーバー主導の利用にはスタンドアロンのJellyfinクライアントを選択してください。

JellyfinのCPUコア数を増やすと、実際にいつ高速化するのか?
Jellyfinでコア数を増やす効果があるのは、制御された低コア数の候補がCPUバウンドになり、同じワークロードがより大きなプロセッサでスケールする場合に限られます。

