Plexのインストールを修復するのではなく、再構築すべきタイミングは？
古いアプリケーションの状態を、信頼できる復旧元として利用できなくなった場合にのみ、Plexを再構築してください。サーバーのID、設定、データベース、ストレージパスが把握できている場合は、まず最小限の失敗レイヤーを修復します。修復に失敗しても、検証済みのバックアップがあるなら、最初からやり直す前に復元してください。
「再インストール」は、必ずしも再構築を意味しません。Plexのパッケージやコンテナを置き換えても、永続化されたデータベースや設定はそのまま残る場合があります。一方、本当の再構築では、その状態を意図的に破棄またはリセットします。判断は現在の症状の苛立たしさではなく、永続データの状態に基づいて行ってください。
選択する前に、修復・復元・再構築を定義する
3つの異なる操作には、3つの異なる言葉を使い分けてください。修復は、現在のPlexの状態を維持しながら、損傷した最小限のコンポーネントを変更します。復元は、損傷した状態を正常性が確認されたバックアップに置き換えます。再構築は、新しいPlexの状態を作成し、一部のライブラリ、メタデータ、環境設定、視聴状況、サーバーIDを再作成または移行する必要が生じる可能性を受け入れるものです。
この区別が重要なのは、アプリケーションのバイナリを再インストールしても、Plexの状態が残る場合があるためです。Western Digitalは、My Cloudの記載されたアンインストール手順では、Plexのライブラリとデータベースが保持され、リセットには別途状態を削除する手順が必要だと説明しています。
再構築を選ぶ前に、実際に壊れているレイヤーを特定してください。パッケージまたはコンテナ、ランタイム定義、ストレージマウント、権限、環境設定、ライブラリデータベースのどれでしょうか。新規インストールで対処できるのは一部のレイヤーだけなので、最初の対応として利用すると、実際の障害を取り除かないまま隠してしまう可能性があります。
元のPlexの状態をまだ信頼できるなら、まず修復する
Plexが期待どおりのサーバーを開き、アプリケーションデータのパスにデータが存在し、データベースもあり、障害を十分に限定して再現できる場合は、まず修復してください。例としては、読み取り可能な復旧経路が残っているデータベースの破損、壊れたインデックス、元に戻せる単一の設定エラーなどがあります。
現在の実践的な手順解説では、Plexを停止し、データベース修復ワークフローで修復ユーティリティを実行してから、サーバーを再起動する方法が紹介されています。インストール全体を破棄するのではなく、既存の状態を維持しながら、損傷したレイヤーを再び有効な状態にできるか検証するという考え方が重要です。
同じサーバーIDが戻り、代表的なライブラリを開け、検索と視聴状況が正常に動作し、通常の再起動でも障害が再発しない場合にのみ、修復を成功と判断してください。修復ツールが失敗を報告した場合、またはデータベースが無効なままの場合は、同じ変更を繰り返すのをやめ、復元の分岐に進みます。
修復しても有効なデータベースに戻せない場合は、復元へ進む
修復に失敗しても、直ちに再構築が必要になるわけではありません。破損する前の検証済みバックアップがある場合は、現在の状態を削除する前に、そのコピーを隔離した場所、または明確に元に戻せる場所へ復元してテストしてください。
実用的なPlexデータベース復旧記事では、修復に失敗した後の次の復旧手段として、データベースバックアップの復元を扱っています。バックアップ自体が健全であれば、クリーンな再構築よりも元のサーバーを多く保持できます。
Plexが復元した状態を開け、想定したライブラリとメディアパスを認識し、データベースエラーを再発させずに再起動できれば、復元の分岐は成功です。利用可能なバックアップがすべて読み取れない、不完全、または同じ破損をすでに含んでいる場合は、再構築に進む基準がかなり近くなります。
状態の元データがない、または信頼できなくなった場合は再構築する
本来なら修復または復元に使用する永続データの元が信頼できない場合は、再構築してください。アプリデータのディレクトリが存在しない、利用できるバックアップがない、データベースを修復または復元できない、あるいは繰り返しテストしても復元した状態が同じ回復不能な障害に戻る、といったケースです。
古いインストールに何年分もの不確かな移行履歴が含まれており、未知の状態を引き継ぎ続けるよりも、新しいサーバーIDを選ぶ場合も、再構築は意図的な選択肢になります。トレードオフは明確です。クリーンな状態にすると破損した履歴は取り除けますが、古いメタデータ、環境設定、関連付けが自動的に引き継がれるという前提も失われます。
繰り返し発生する破損を、クリーンなPlexデータベースだけが問題だという証拠にしないでください。新しく再構築した状態も再び破損するなら、ファイルシステム、ストレージデバイス、突然の電源断、メモリの安定性、その他の根本原因を調査してください。信頼性のない状態保存レイヤーを、アプリケーションの再構築で信頼できるものに変えることはできません。
コンテナ、マウント、権限の障害で再構築しない
起動しないコンテナ、空のメディアマウント、権限エラー、ネットワークエイリアスの欠落によって、Plexが完全に壊れているように見えても、永続状態は健全なままの場合があります。これらはランタイムまたは依存関係の障害であり、ライブラリデータベースを破棄すべき証拠ではありません。
ZimaSpaceの単一コンテナの復元ワークフローでは、ボリュームと正常な依存関係をそのまま維持し、失敗したサービスレイヤーだけを置き換えます。Plexの状態は完全でも、その周囲のランタイムが変更された場合に適した、より安全な方法です。
正しいマウント、ID、ネットワーク、またはコンテナ定義を再接続することで元のサーバーが戻ったなら、そこで止めてください。再構築しても、永続状態の問題が確認されていない限り、移行作業が増えるだけです。障害がアプリケーションの状態自体に追随する場合にのみ、復元または再構築へ進んでください。
新しく始める前に、証拠と復旧ポイントを保存する
本当の再構築を行う前に、古いアプリデータのツリー、データベースのバックアップ、環境設定、デプロイ定義、ログ、修復を断念する決め手となった正確なエラーを保存してください。破損した状態であっても、視聴履歴、メタデータ、設定の詳細など、移行や事後検証に役立つ情報が含まれている可能性があります。
ストレージに余裕がある場合は、古いデータをその場で上書きせず、保存した復旧ポイントの隣に新しいサーバーを構築してください。まず代表的なライブラリを1つ追加し、新しいデータベースを確認してから、信頼できると意図的に判断した状態だけを移行します。これにより、新しいサーバーが元の障害を実際に解決したと確認するまで、「最初からやり直す」作業を元に戻せます。
最終的な判断は簡単です。現在の状態を信頼できる間は修復し、損傷した状態を置き換えられる正常なコピーがある場合は復元し、どちらの方法でも再現可能な有効なサーバーを作れない場合にのみ再構築します。クリーンなインストールが通常の利用、再起動、新しいバックアップに耐えることを確認するまで、以前の証拠を保管してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
