Jellyfinをライブ状態でバックアップすべきか、それとも先にサービスを停止すべきか？
アプリケーションが書き込み中でも、その状態を一貫して取得できるスナップショット方式でない限り、完全バックアップを確実に行うにはJellyfinを停止してください。
トレードオフは、ダウンタイムと整合性です。サービスを停止して作成するアーカイブは、コピー中にデータベース、設定、メタデータが変更されないため、判断が簡単です。データベースのバックアップ機構やファイルシステムのスナップショットによって一貫した時点を取得できる場合は、ライブバックアップでも有効です。しかし、書き込み中に通常の再帰コピーを行う方法は、信頼性の判断が難しくなります。
サービス停止中のコピーが、シンプルで安全な基本方法
Jellyfinを短時間停止すると、バックアップツールが設定ツリーを走査している間に、新しいデータベースやメタデータへの書き込みが発生しません。小規模なホームサーバーでは、これにより多くの整合性に関する懸念を解消できます。
ライブファイルコピーでは、WALによって管理されるトランザクションを取りこぼす可能性があります。トランザクション対応のSQLiteバックアップなら、開いているデータベースを通常の静的ファイルとしてコピーすることを避けられます。
利用者の少ない時間帯に停止をスケジュールし、プロセスが停止したことを確認してから永続データをコピーし、再びサービスを起動してください。停止時間を測定して、実際の運用上のコストを把握しましょう。
ライブバックアップには一貫したスナップショット機構が必要
ファイルシステムのスナップショットは、稼働中のサービスがその後も動作し続けている間に、多数のファイルをある瞬間の状態として固定できます。これは、変更され続けるファイルを1つずつ時間をかけてコピーする方法とは異なります。
バックアップ中もアクティブなデータセットは変化します。そのため、取得に時間がかかる場合は変更量が重要になります。
ZFS、Btrfs、またはデータベース対応のバックアップを使用する場合は、どのような整合性保証が提供されるのかを文書化してください。テストせずに、単純なライブファイルコピーと同等だと考えてはいけません。
バックアップの完了よりデータベースの整合性が重要
バックアップジョブが成功を返しても、取得されたデータベースが復旧に使用できる状態とは限りません。検証では、データベースとアプリケーションの状態を一緒に確認する必要があります。
信頼できる復旧セットでは、書き込み中のデータベースを無制御にコピーしないようにしてください。SQLiteの整合性は、一貫したデータベース状態を維持できるかどうかに左右されます。
バックアップを使い捨てのパスに復元し、依存する前に整合性チェックを実行してください。永続アプリデータのレイアウトでは、状態が交換可能なコンテナから分離されているため、このテストを簡単に実行できます。
復旧目標に合わせて方法を選ぶ
2分間のメンテナンス時間を許容できる家庭であれば、複雑なライブバックアップの仕組みを導入しても、得られるメリットはほとんどないかもしれません。厳格な稼働時間の目標があるサーバーでは、スナップショットを導入する価値があります。ただし、復元を予測どおりに行える場合に限ります。
適切な災害復旧テストでは、選択したバックアップによってサービスを実用可能な状態に戻せるかどうかを測定します。
バックアップの停止時間、復元時間、障害時の複雑さを比較してください。家庭の復旧目標を満たし、実際の復元リハーサルにも耐えられる、最もシンプルな方法を選びましょう。
おすすめ商品
サポートとヒント
もっと読む
誰もストリーミングしていないのに、Jellyfinが高温になったり、動作音が大きくなったりするのはなぜですか？
アイドル時の発熱は通常、バックグラウンド処理または共有ホストのワークロードを意味するため、冷却やハードウェアを変更する前に、実行中のプロセスとスケジュールされたタスクを特定してください。
Jellyfinは修理より再構築すべきタイミングとは？
ランタイムの不整合が問題で、永続状態がバックアップされている場合は、修復より再構築を選択してください。ただし、唯一の正常なデータベースを削除して「再構築」してはいけません。
Jellyfinはバックグラウンドジョブ用にどのくらいの空き容量を確保すべきですか？
Jellyfinに適した一律の空き容量率はありません。永続的な増加と一時的なピークを別々に測定し、その両方を上回る余裕を確保してください。
