段階的な移行を行いましょう。Plexの状態を保持し、新しいメディアパスが機能することを確認し、移行先を検証してから、切り替えが完了するまで旧サーバーには手を加えないでください。
新しいホームサーバーはより高速でクリーンにできますが、移行を単なるメディアのコピーとして扱うと、視聴履歴、サーバーID、アートワーク、権限、リモートアクセスを失う可能性があります。まず稼働中の移行元を固定し、アプリケーションの完全な状態が保存されている場所を特定します。次に、検証済みのストレージパスと権限を基に移行先を構築し、元の環境を破壊せずにテストします。想定した状態が欠けている場合は、移行を中断してください。
コピーを始める前に移行元を固定する
移行期間が始まったら、旧サーバーを稼働中の唯一の正しい情報源として扱うのをやめます。Plexのバージョン、サーバー名、ライブラリパス、コンテナまたはサービスの設定、アカウントの状態、完全なPlexデータディレクトリの場所を記録します。移行先がすべての検証チェックに合格するまで、元のホストはそのまま維持してください。
メディアファイルを保持できても、サーバーデータに保存された視聴状態を失うことがあります。そのため、メディアだけをコピーすることは、サーバーを移行することと同じではありません。
最初の変更を行う前に、ロールバックポイントを作成します。アプリケーションの状態を検証済みのコピーとして保存し、元のホストを再起動する方法を文書化してください。データベースやパスを変更せずに旧サーバーへ戻せないのであれば、その移行はすでに必要以上にリスクの高いものになっています。
Plexの状態をメディアライブラリとは分けて保持する
永続的なPlexデータディレクトリには、データベース、環境設定、メタデータ、アートワーク、インデックスなど、動作に必要な状態が保存されています。メディアライブラリは容量とバックアップ計画が別の、もう1つのデータセットです。これらを別々の単位としてコピーすると、新しいホストが空の状態で起動した場合やファイルを見つけられない場合に、どの部分で問題が起きたのかを確認しやすくなります。
視聴履歴の移行はPlexデータベースに依存します。そのため、移行先が何かを再スキャンする前に、ユーザーが利用する状態を保護しておく必要があります。
コンテナを使用している場合は、`/config`とすべてのメディアパスについて、ホストとコンテナ間のマッピングも記録します。ネイティブインストールの場合は、プラットフォーム固有のデータ保存場所を記録してください。実際の状態をどこに配置するか決めている間、移行先が空のディレクトリを使って何度も起動しないようにします。
移行先のメディアパスを意図的に設定する
データベースの移行に成功しても、新しいオペレーティングシステムやコンテナからアクセスできないメディアの場所を指していることがあります。可能であればパスを同じに保ち、変更する場合は明確に計画してください。予期しないマウント構成の下で、Plexにライブラリ全体を再検出させることがないようにします。
サーバーの完全な状態を保持できない場合、視聴履歴の移行が、ライブラリを再構築した後に別途復旧する作業になる可能性があります。
移行先でPlexを起動する前に、ストレージをマウントし、サービスアカウントが各ライブラリ内の実際のファイルを複数読み取れることを確認します。ファイルレベルのテストに失敗した場合は、まずストレージと権限を修正してください。Plexの再スキャンで、マウントされていないストレージを修復することはできません。
移行先を分離した検証状態で起動する
移行先を起動しても、すぐに家庭内で依存する唯一のサーバーにしないでください。移行した状態が正しく開くことを確認するまで、負荷の高いスキャンやバックグラウンドジョブは無効にするか延期します。サーバーID、ライブラリ数、ユーザー、プレイリスト、コレクション、視聴状況、複数のランダムなメディア項目を確認します。
切り替えの前に、明確な検証フェーズを設けます。サーバーID、ライブラリ数、ユーザー、コレクション、視聴状況、アートワーク、代表的な再生結果を比較してください。移行先は、Webインターフェースが表示されるだけでなく、想定した状態と一致している必要があります。
移行先に初期設定ウィザードが表示されたり、ライブラリが見つからなかったり、アートワークが空になっていたりする場合は、置き換えを作成せずに停止します。データディレクトリのマッピングと所有者を再確認してください。意図せず空の状態に新しいデータを書き込むたびに、移行データと移行先が生成した状態を区別しにくくなります。
アートワーク、権限、単一のライブラリパスなど、1種類の状態だけに問題がある場合は、その境界を修正して同じ検証項目を繰り返します。移行したデータベース自体が使用不能だと確認できるまでは、部分的な不一致をライブラリ全体の再スキャンに発展させないでください。
再生と復旧の両方に合格してから切り替える
移行を正常に切り替えるには、ローカルでのダイレクト再生、必要なトランスコード、リモートアクセス、別ユーザーでの利用、ライブラリの変更、再起動、そして移行後の状態の検証済みバックアップが必要です。
安全なPlex移行ワークフローでは、アプリケーションの状態、メディアパス、権限、ロールバックを同じ切り替え判断に含めます。この一連の経路を完了してから、移行元を廃止してください。
移行先が完全なテストに合格して初めて、旧サーバーを完全に停止します。少なくとも通常のメンテナンスサイクルを1回終えるまで、移行元のバックアップを保持してください。後のスキャンやアップデートで状態の欠落が見つかっても、別の再構築作業を始めるのではなく、正常な復旧ポイントを利用できます。
サポートとヒント
もっと読む

Plexは別のDockerコンテナとGPUを共有できますか?
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。

Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。

Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。

