不整合なデータベースを取得せずに Plex をバックアップする方法
Plexのアプリデータ全体をバックアップする場合は、ファイルシステムのコピーまたはスナップショットを作成する前にPlexを停止してください。コアデータベースだけを対象にする場合は、Plexのスケジュールバックアップがアプリケーション対応の方法です。
サーバーの稼働中、Plexはデータベース、メタデータ、設定、キャッシュに書き込みます。そのため、一般的なバックアップジョブでは、異なる時点のファイルが取得される可能性があります。これは、稼働中のバックアップがすべて破損するという意味ではありません。ただし、アプリケーションまたはストレージ層が整合性を調整しない限り、生のファイルコピーは信頼性の判断が難しくなります。まず、必要なのがPlexのコアデータベースだけなのか、サーバー全体の状態なのかを決めてください。そのうえで、対象範囲に合った方法を使い、バックアップ完了と判断する前に復元手順を検証しましょう。
コアデータベースのバックアップとサーバーデータ全体のバックアップを分ける
Plexのスケジュールタスクでは、視聴状態やマッチング情報を保持するコアデータベースをバックアップできます。これはデータベースの復旧に役立ちますが、Plexは、これがPlex Media Serverのデータディレクトリ全体のバックアップの代わりにはならないと明示しています。一つのファイルですべてをカバーできると考えず、これら2種類のバックアップを異なる復旧手段として扱ってください。
Plexのバックアップに関するドキュメントでは、メインのサーバーデータディレクトリをバックアップすることを推奨しており、一部のプラットフォームではキャッシュを除外できると説明しています。一時的なキャッシュによってアーカイブが不必要に大きくならないよう、重要なデータベースとメタデータの状態を保護しつつ、バックアップ対象を意図的に定義してください。
目的が「サーバーを完全に元の状態へ戻す」ことであれば、永続的なアプリデータツリーと、Plexが必要とするプラットフォーム固有の設定を含めてください。目的が「視聴状態とコアライブラリデータベースだけを復旧する」ことであれば、スケジュールされたデータベースバックアップを、より小規模で対象を絞った予備手段として利用できます。
生のファイルシステムコピーの前にPlexを静止させる
単純なファイルレベルのバックアップでは、Plexコンテナを停止し、永続データパスのコピーまたはスナップショット作成を始める前に、終了したことを確認してください。停止時間は短く保ちます。停止、整合性の取れた時点の取得、再起動を行い、ファイルシステムがそのワークフローに対応している場合は、スナップショットから時間のかかるオフホストへのコピーを続けます。
SQLiteのバックアップAPIのドキュメントは、稼働中のデータベースコピーが単なるファイルサイズの問題ではなく、調整を必要とする問題である理由を示しています。アプリケーション対応バックアップまたは静止させたスナップショットなら、データベースの状態を明確に定義できます。一方、変更中のデータベース、WAL、メタデータのファイルを無計画にコピーすると、復旧時点の確実性が低下します。
NASで瞬時にスナップショットを作成できるなら、大規模なバックアップが低速ストレージを走査する間、Plexを何時間も停止させないでください。安全な方法は、短時間書き込みを停止して整合性を確立し、その後、サービスを再開できるスナップショットまたはアーカイブのワークフローで、バックアップを別の場所へ移すことです。
ログ、キャッシュ、永続状態に異なる復旧ルールを適用する
キャッシュや詳細ログは急速に変化する可能性があり、通常、Plexのデータベースやメタデータと同じ保持期間は必要ありません。これらのパスを分けると、バックアップが小さくなり、復元範囲も明確になります。また、ログやキャッシュのツリーが肥大化して、アプリケーション状態用に確保した容量を消費することも防げます。
コンテナログとアプリデータの分離に関するZimaSpaceのガイドでは、アプリの状態、ログ、キャッシュにはそれぞれ異なるライフサイクルと復旧要件がある理由を説明しています。3つすべてを一つのコンテナ設定で開始していても、Plexには同じポリシーが有効です。
バックアップ範囲を変更した場合は、使い捨てのコピーまたは分離したコンテナを使って、復元テストを1回実行してください。バックアップポリシーは、アップロードが成功しただけでは検証できません。復元したデータベースとメタデータをPlexが開き、期待どおりのサーバー状態を表示できたときに初めて検証されたことになります。
既知の状態を復元してバックアップを検証する
復元後に検証できる事実をいくつか選びます。サーバー名、1つのライブラリ、1つの視聴済みアイテム、1つの途中まで視聴したアイテム、そして把握している設定を対象にしてください。テスト復元では、Plexに新しいサーバーの作成やメディアファイルからのライブラリ再構築を要求することなく、これらの情報が復元される必要があります。
Plexは、サーバーを停止してアクティブなデータベースをバックアップに置き換えることから始めるデータベースの復元手順を公開しています。完全バックアップの方法が異なる場合でも、データベースを置き換える前にサーバーを停止するという境界は、復旧時の有用なルールです。
復元テストに失敗した場合は、保持期間を延ばしたりコピーの自動化を進めたりする前に、バックアップ方法を修正してください。既知の正常なバックアップを復元できない場合に限ってデータベース修復を検討し、破損した稼働中のデータベースを使って試行錯誤する際に、最後の復元可能なコピーを上書きしないでください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
