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