問題のあるサーバーアップデート後にPlexを安全にロールバックする方法
ダウングレードする前に Plex のデータディレクトリをバックアップし、新しいリリースによってデータベースの互換性が変更されていないか確認してから、1バージョンずつロールバックしてください。
Plex のロールバックは、バイナリや Docker イメージを置き換えるだけではありません。アップデートによってサーバーのデータベースが移行されることがあり、古いサーバーは新しいサーバーによって書き込まれた状態を認識できない場合があります。まず現在のデータを保全し、最後に正常動作していたビルドを特定して、ロールバックを元に戻せる状態にしてください。目的は、ソフトウェアの問題をデータベース復旧の問題に変えることなく、アップデートが不具合の原因だったと検証することです。
サーバーのバージョンを変更する前に現在の状態を固定する
Plex を正常に停止し、永続化されているサーバーデータディレクトリのコピーを作成します。現在のサーバーバージョンと、ロールバックの対象となる正確な症状を記録してください。Docker を使用している場合は、現在のイメージタグまたはダイジェストと、以前正常に動作していたタグも記録します。これにより、「latest」とキャッシュされていた不明なイメージとの比較ではなく、明確なロールバックになります。
最近の Plex フォーラムでの復旧例では、サーバーの Updates ディレクトリに以前のインストーラーが存在する可能性について触れ、以前のサーバーバージョンへのロールバックについて説明しています。これはバージョンに依存する運用上の参考情報として扱い、すべてのプラットフォームで同じ方法でパッケージが保存されていると考えないでください。
ロールバックの最初の手順として、現在のデータベースや設定を削除しないでください。古いビルドが失敗した場合、ロールバック前の状態に戻るために、変更されていないバックアップが必要です。安全なロールバックでは、古いビルドに戻る方向と、現在のビルドに再び進む方向の両方を常に維持します。
ダウングレード前にデータベース移行の境界を確認する
インストールしたバージョンのリリースノートや既知の不具い議論を確認してください。Plex の一部のリリースではデータベース互換性が変更されているため、古い実行ファイル自体は正常にインストールできても、バージョンを大きく遡ると失敗することがあります。移行の境界がある場合は、サポートされている中間バージョンの手順に従うか、互換性のあるデータベースバックアップを復元し、新しい状態に対して古いサーバーを無理に実行しないでください。
1.40 の移行に関する Plex コミュニティの案内では、データベースの互換性によってロールバックの経路が制限されたケースが具体的に記録されています。このケースに登場する正確なバージョン番号は過去のものですが、現在のリリースについてダウングレード前に移行の境界を確認するという原則は変わりません。
Plex が現在データベースの移行を実行している場合、ロールバックを急ぐために中断しないでください。移行が完了するまで待つか、互換性が確認されたバックアップを復元します。スキーマ処理を中断すると別の障害状態が発生し、元の問題の原因がリリース自体にあったかどうかを検証しにくくなります。
他の変数を変更せずに以前のビルドをインストールまたは固定する
変更するのは Plex サーバーのバージョンだけにします。同じアプリデータのマウント、メディアパス、ネットワークモード、ハードウェアデバイス、クライアント設定を維持してください。Docker では可変タグに頼らず、以前のイメージタグを固定します。パッケージベースのインストールでは、そのプラットフォームに適した信頼できる入手元から以前のインストーラーを使用します。
ZimaSpace のホームサーバー復旧チェックリストでも、読み取り可能な状態を保全し、どの層で障害が発生しているかを特定して、最初から誤ったコンポーネントを交換または再構築しないという同じ復旧原則を採用しています。Plex のロールバックも同様に、変更範囲を限定してください。
Plex を起動し、再生テストを行う前にデータベースエラーがないかログを確認します。古いビルドがデータベースを拒否したり、新しいサーバーとして起動したりした場合は、直ちに停止し、保護しておいた状態を復元してください。互換性のないデータディレクトリに新しいファイルを書き込ませないことが重要です。
ロールバックを継続するか判断する前に、元の不具合を再現する
古いビルドが正常に起動したら、アップデート後に発生した問題を正確に再現します。同じクライアント、メディア、ネットワーク経路、ライブラリ操作、またはスケジュールタスクを使用してください。ロールバックによってリリースが関与していたと証明できるのは、以前のバージョンで元のトリガーが正常に動作し、サーバーの他の部分も健全な場合だけです。
Plex を一度再起動してから同じトリガーを再度実行し、通常のライフサイクルイベント後も復旧状態が維持されることを確認します。そのうえで、ライブラリへのアクセス、視聴履歴、使用している場合はリモートアクセス、さらにアップデートの影響を受けた可能性のあるハードウェアトランスコード経路を確認してください。ホーム画面が表示されたというだけで成功と判断しないでください。
以前のビルドでも失敗する場合は、保護しておいた現在の状態に戻し、さらにダウングレードを重ねるのではなく、診断を続けてください。以前のビルドで問題が解消した場合は、ロールバックを一時的な対応にとどめ、動作するバージョンを記録し、再度アップグレードする前に不具合を解消する後続の Plex リリースを待ちます。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
