Plexのバックアップが実際に復元可能かテストする方法
Plexのバックアップは、そのコピーからクリーンな環境でサーバーの状態、権限、ライブラリ、代表的な再生動作を再構築できて初めて実証されます。
ファイル数やコピー処理の成功は、復元テストにはなりません。分離された実行環境、複製または読み取り専用のメディアパス、文書化された所有権を使用し、復旧時に本番環境の隠れた依存関係を借りないようにします。保持期間によって後から判明する障害への備えが求められる場合は、直近の時点と古い時点の両方をテストしてください。
クリーンな実行環境から始める
復元テストは、稼働中のコンテナ、データベース、メタデータパスをマウントしない状態で開始してください。そうしないと、本番環境の状態がまだ利用できるためにテストが成功する可能性があります。
独立した復元テストでは、アーカイブの存在を確認するのではなく、利用可能なサービス動作を再構築することでバックアップを検証します。
使い捨てのコンテナまたはホストを作成し、コピーしたバックアップと、破壊的な変更を行わないメディアアクセスだけを接続します。ログインページに到達するために必要な手動手順をすべて記録してください。
識別情報、ライブラリ、権限を検証する
サーバーは起動しても、ライブラリ間の関連付け、アカウントポリシー、書き込み権限が失われている可能性があります。受け入れテストには、これらの動作を含めてください。
コンテナ化した復元で、所有権の異なるホストへ状態を移行する場合は、正しいUIDとGIDのマッピングが必要です。
代表的なライブラリを開き、影響のない状態変更を行い、制限付きアカウントと制限のないアカウントを確認します。文書化されていないroot権限を適用するのではなく、復旧手順を修正してください。
最新のコピーだけでなくテストする
最新のバックアップは、気付かれない破損や不適切なアップデートの後に取得されている可能性があります。保持は、既知の正常な古い時点も選択して復元できる場合にのみ役立ちます。
有用なバックアップ履歴では、障害がシステムに入り込む前の既知の正常な復旧ポイントを保持します。
定期的に、直近の時点と古い時点を1つずつ復元してください。最新のコピーしかテストしない場合、古い保持階層はまだ実証されていません。文書化された家庭用メディアサーバートポロジにより、実際のインシデントが発生する前に、復元先、メディアパス、バックアップの障害ドメインを明確にしておく必要があります。
復旧時間を測定する
技術的に復元が成功しても、家庭で許容できる停止時間の目標を満たせない場合があります。処理時間を測定し、最も時間のかかる手動作業やストレージ処理を特定してください。
多くのホスト移行は、特にアプリケーションデータとマウントパスの一貫性を保つ必要がある場合、状態の移行によって成否が決まります。
空の実行環境から再生を検証するまでの時間を記録します。ストレージ構成、権限、またはバックアップツールを変更した後にも繰り返し、見積もりの信頼性を維持してください。
おすすめ商品
サポートとヒント
もっと読む
Jellyfinをライブ状態でバックアップすべきか、それとも先にサービスを停止すべきか？
シンプルさを重視するならサービスを停止してバックアップする方法を優先し、アプリケーションの状態が一貫して取得され、復元テストも実施済みの場合に限り、稼働中のスナップショットを使用してください。
誰もストリーミングしていないのに、Jellyfinが高温になったり、動作音が大きくなったりするのはなぜですか？
アイドル時の発熱は通常、バックグラウンド処理または共有ホストのワークロードを意味するため、冷却やハードウェアを変更する前に、実行中のプロセスとスケジュールされたタスクを特定してください。
Jellyfinは修理より再構築すべきタイミングとは？
ランタイムの不整合が問題で、永続状態がバックアップされている場合は、修復より再構築を選択してください。ただし、唯一の正常なデータベースを削除して「再構築」してはいけません。
