安全な復旧に必要なPlexバックアップの保持期間はどのくらい？
Plexのバックアップコピーには一律の正解数はありません。必要なのは、障害が発生する前の正常な状態まで戻れる、検証済みの履歴を十分に確保することです。
保持期間は、Plexの状態が変更される頻度、破損に気付くまでの早さ、アップデートや誤ったライブラリ操作の後にどこまでさかのぼる必要があるかをカバーする必要があります。検証されていないコピーを大量に保管しても、すべて同じ問題が発生した後に取得されたものなら復旧できません。まず目標復旧時点と目標復旧時間を定義し、そのうえで日次、週次、スナップショットの各階層を選びましょう。
取り消す必要がある障害から考える
誤削除、問題のあるアップデート、気付きにくいデータベース破損、ディスク全体の損失では、発見までにかかる時間が異なります。最新のバックアップ1つだけでは、すぐに発見できる障害しか保護できません。
保持期間は、単に最新のコピーを残すのではなく、障害が発生する前の正常な復旧ポイントまでさかのぼれる長さにします。
想定する障害を列挙し、発見までに現実的にかかり得る最長時間を見積もります。最初にコピー数を決めるのではなく、その期間を超えてバージョン履歴を保持してください。
複数の時間スケールを使う
最近の頻繁なコピーは現在の視聴状況や設定を保護し、過去の間隔が長いコピーは発見が遅れた問題からの復旧に役立ちます。階層化したスケジュールなら、すべてのスナップショットを永久に保持せずに両方をカバーできます。
時点別のバージョンを使えば、すべての時点で完全な複製を保持しなくても、最近と過去の復旧先を確保できます。
短い間隔で取得する最近のコピーと、長い間隔で取得する過去のコピーを組み合わせ、利用可能なストレージに収まるようにします。各階層の有効期限と、対象とする障害の種類を文書化してください。
保持期間をオフデバイス保護の代わりにしない
同じ故障しかけたディスクに10個のバージョンを保存していても、障害ドメインは1つのままです。保持期間と冗長化は、異なる問題を解決します。
バックアップ容量と変更量は、稼働中のPlexデータパスとは分けて計画し、保持データが1つの障害ドメイン内にとどまらないようにします。
少なくとも1つの復旧用コピーを稼働中のアプリデータデバイスの外部に保管し、そのコピーを独立してテストしてください。ホームサーバーの構成では、バックアップの障害ドメインを同じプール内に隠さず、明確に把握できるようにする必要があります。
復元テストに合格してから削除する
古いコピーから実際に想定どおりデータベース、メタデータ、識別情報を復元できて初めて、保持期間は役に立ちます。定期的に実行されるローテーション処理だけをテスト対象にしてはいけません。
削除する前に、最近のコピーと古いコピーの両方を使って、使い捨てのPlexインスタンスへ復元します。復元テストによって、完了したバックアップが実際に復旧可能であることを確認できます。
古いバックアップが繰り返し失敗したり、文書化されていないパスに依存したりする場合は、保持期間を短縮する前に取得方法を修正してください。保持すべきなのは単なるタイムスタンプではなく、信頼できる復旧の選択肢です。
おすすめ商品
サポートとヒント
もっと読む
Jellyfinは別のコンテナとGPUやアクセラレーターを安全に共有できますか？
GPUの共有には条件があります。デバイスが認識され、ドライバーが対応していることを確認してから、両方のワークロードを実行し、ソフトウェアフォールバックが発生していないか監視してください。
Jellyfinのエラーがクライアントとサーバーのどちらに起因するかを見分ける方法
Jellyfinのエラーが特定の1台のデバイスにだけ発生する場合はクライアント側に原因があり、同じ経路で複数のクライアントが失敗し、ログも一致する場合はサーバー側に原因があります。
Jellyfinのキャッシュと一時ストレージの設定方法
永続的なデータ、再構築可能なキャッシュ、一時的なトランスコード用ストレージを分離し、実際に再生テストを行って容量と権限を確認します。
