デスクトップから専用メディアサーバーへPlexを移行する方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Migrate Plex From a Desktop to a Dedicated Media Server - Zima Store Online

Plexは、アプリケーション状態、メディア、パス、ロールバックを分離して移行し、エンドツーエンドの検証後にのみ、専用サーバーを正式な運用先にします。

家庭の管理者にとって、本当の移行とは、静かなハードウェアにPlexを新規インストールすることではありません。新しいサーバーは、家族がすでに頼りにしているライブラリ、ユーザー、視聴状態、アートワーク、ストレージアクセス、再生動作を再現する必要があります。代表的なストリーム、リモートアクセス、再起動、バックアップ、隔離環境での復元に合格するまで、ロールバック用ホストとしてデスクトップをそのまま維持し、書き込みを行わない状態にします。

Plex移行で正確に保持すべきものを定義する

現在のデスクトップは、複製するフォルダーの山ではなく、稼働中のソースとして扱うことから始めます。各Plexライブラリ、そのメディアのルート、サーバー名、管理対象ユーザーと共有関係、リモートアクセス経路、スケジュールタスク、ファイル名やフォルダー内容を変更する関連サービスを記録します。実際に使用するすべてのクライアント種別（テレビ、スマートフォン、ブラウザー、タブレット、リモート接続）ごとに、代表的な映画またはエピソードを1本追加します。

Plexの復旧単位を、明確に異なる役割へ分けます。永続的なアプリケーション状態には、ライブラリデータベース、環境設定、ポスター、インデックス、アカウントの関連付け、視聴履歴が含まれます。コピーしたPlexデータディレクトリは、移行時にその状態を維持すれば、表示状態、メタデータ、設定を引き継ぎます。メディアファイルは、これとは別の正式なデータセットです。トランスコードファイルや一時的な派生ファイルは、再構築可能なキャッシュです。オペレーティングシステムとPlexのバイナリは、復旧可能な唯一のコピーとして扱うのではなく、書面化したインストール記録から再現できるようにします。

デスクトップを変更する前に、受け入れチェックリストを作成します。最低限、ライブラリ数、既知の視聴位置、管理対象ユーザーの表示範囲、アートワーク、字幕再生、高ビットレートのローカルストリーム1本、リモートストリーム1本、再起動後のサービス自動起動を比較できる内容にします。古いライブラリ、未使用のプラグイン、放置されたフォルダーには、意図せず過去の履歴を専用サーバーへ持ち込むのではなく、「廃止」と印を付けます。保持するすべての項目に、ソース、移行先、担当者、テストが割り当てられて初めて、インベントリは完成です。

ライブラリの容量ではなく、実際の再生状況を基準に専用サーバーのサイズを決める

テラバイト数が示すのはストレージ容量であり、再生負荷ではありません。コンピューティング性能の判断は、クライアントが直接再生できるもの、再多重化またはトランスコードが必要なファイル、重複するセッション数、字幕によって動画変換が発生するかどうか、リモート視聴者が受け取れる上り帯域幅によって決まります。Direct Play には十分な帯域幅が必要です。また、互換性のあるクライアント設定も必要で、どちらか一方でも条件を満たさない場合、サーバーは再多重化またはトランスコードを行わなければならないことがあります。小規模なライブラリでも、互換性のないリモートクライアントが 2 台同時にトランスコードするとピーク負荷が高くなる可能性があります。一方、大規模なライブラリでも、ローカルクライアントがその形式を Direct Play できれば負荷は軽いままです。

最も負荷が高い現実的なパターンで、既存のデスクトップを測定します。代表的な高ビットレートの動画をローカルで再生し、リモート接続からも繰り返し再生します。家庭で使用する字幕を有効にし、1 台のクライアントで意図的に低画質を要求します。各セッションが Direct Play、Direct Stream、トランスコードのいずれになったかに加え、CPU、アクセラレーター、メモリ、ディスク、ネットワークのピーク使用量を記録します。単一の合成スコアを掛け合わせるのではなく、同時セッションをテストします。

このベースラインが整ってからターゲットを選定します。実際にトランスコードが必要な形式に対して十分なデコードおよびエンコード対応、合計 Direct Play ビットレートを上回るネットワーク余裕、現在のメディアと測定した増加量の両方に対応できるストレージ容量が必要です。ハードウェアアクセラレーションを計画に含める場合は、オペレーティングシステムまたはコンテナからデバイスを認識できることを確認し、実際のストリームで動作を検証します。仕様書は受け入れテストではありません。

候補サーバーが余裕を確保したうえで測定済みのピーク負荷に耐えられない場合は、この段階で移行を中止します。性能不足のターゲットにアプリケーションの状態を移すと、進展に見せかけた障害を招きます。ターゲットを変更するか、必要な同時実行数を減らすか、クライアント互換性を高めるか、権威データをコピーする前にストレージとトランスコード用コンピューティングを意図的に分離してください。

Plex の状態、メディア、キャッシュ、バックアップを分離する

Plex を復元する前に、安定した役割を中心に専用サーバーを構築します。ブート用およびアプリケーション用のバイナリは、交換可能なシステム層に配置します。永続的な Plex アプリケーションデータは、データベースやアートワークの増加に十分な空き容量があるパスに保存します。ドライブを交換しても変わらない安定した場所にメディアをマウントします。一時トランスコードの保存先には使い捨て可能な層を指定し、保護対象となるすべてのライブ層の外部にバックアップを保管します。

役割	配置先	必要なアクセス	保護と復元
システムおよび Plex のバイナリ	交換可能なブート層	起動後にサービスを開始可能	記録したインストール手順から再構築
Plex のアプリケーション状態	永続アプリデータ層	Plex による読み取りと書き込みが可能	バージョン付きコピー。Plex の起動前に復元
メディアファイル	安定メディア層	Plexは読み取り可能、書き込み元は明示的に指定	交換費用に応じた独立バックアップ
トランスコードキャッシュ	使い捨ての高速ティア	Plexによる作成と削除が可能	復元せず、空の状態から再作成
復旧用コピー	稼働中のサーバーの外部、またはサーバーから分離された場所	バックアップジョブは書き込み、復元ジョブは読み取る	別の移行先に対してテストする

権限はトポロジーの一部です。Plexを実行するアカウントまたはコンテナには、アプリケーション状態とキャッシュへの書き込み権限に加えて、すべてのメディアルートへの読み取り権限が必要です。Plexサービスアカウントには、メディアディレクトリをたどって配信するファイルを開けるよう、メディアディレクトリに対する読み取りおよび実行権限が必要です。メディアを書き込むプロセスには、より広い権限が必要になる場合がありますが、Plexはファイルをストリーミングするだけなら、管理者権限を全面的に付与する必要はありません。ディレクトリの通過とファイルの読み取りの両方を確認してください。親ディレクトリがサービスの識別情報によるアクセスを阻止していれば、読み取り可能な映画でも到達できません。

古いメディアルートごとに、新しいマウント先またはコンテナパスを対応付けたパスマップを保存してください。コンテナ側のパスを一貫させると、将来のホスト変更が容易になります。一方、ホスト側のマウントはストレージ構成に合わせて設定できます。Plexの起動前にストレージがマウントされること、またマウントが欠落した場合に、誤ったライブラリスキャンを引き起こす可能性のある空のディレクトリを表示するのではなく、目に見える障害になることを確認してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

同一プラットフォームまたはクロスプラットフォームの状態保存先を選択

同じオペレーティングシステム間での移行は、アプリケーションデータの構成、設定の保存方法、パス構文、サービスの識別情報が一致する可能性が高いため、通常はリスクの低い方法です。移行先に互換性のあるPlexバージョンをインストールし、移行先の構成を作成させてから停止し、使い捨てのソース状態のコピーで復元をテストしてください。復元したデータベースとパス計画の準備が整う前に、クリーンなインスタンスで実際のメディアをスキャンさせないでください。

WindowsからLinux、macOSからコンテナ、またはその他のクロスプラットフォーム移行では、変換作業が増えます。クロスプラットフォーム移行では、移行先によってパスやサーバー設定の保存方法が異なるため、パスと設定の変換が必要になる場合があります。ドライブレター付きのパスはマウントされたディレクトリに変わることがあり、設定の保存先も別の場所になり、サービスアカウントの識別情報も変わります。コンテナホスト側のパスとコンテナから見えるパスは、別々に決めるものとして扱ってください。データベースだけをコピーすれば、こうした参照先も変換されるとは決して考えないでください。

場当たり的なデータベース編集よりも、サポートされた移行ワークフロー、または同一プラットフォーム上の中間ステップを優先してください。プラットフォーム固有の手順で状態変換が必要な場合は、バックアップを2つ作成し、使い捨てコピーだけを操作し、すべての変換を記録してから、権威あるソースに触れる前にライブラリルートとサーバーIDを検証してください。標準のデータベースブラウザーや汎用の検索・置換ツールは、意図したパス以外も変更する可能性があるため、検証されていない編集は中止条件です。

判断の終了条件は二者択一です。復元したコピーがテスト用パスに対して期待されるサーバーとライブラリを提示するか、クロスプラットフォーム移行の準備が整っていないかのどちらかです。元の視聴状態、共有、継続性を失うことを明確に選択したのでない限り、IDの移行に失敗した埋め合わせとして、無関係な2台目のPlexサーバーを作成し、全員を再招待しないでください。

デスクトップを凍結し、権威ある復旧単位を1つコピーする

対象プラットフォーム、パス、権限のドライランが正常に完了した後、短時間の書き込み凍結を予定してください。メディアパスが一時的に利用できなくなった際にエントリを削除する可能性のある自動クリーンアップを無効にしてください。デスクトップ上のPlexを停止し、プロセスが書き込みを行っていないことを確認してください。最終状態のコピーを開始する前に、時刻、ソースアプリケーションのバージョン、ライブラリルート、最後に正常だったバックアップを記録してください。

移動ではなくコピーしてください。ソースプラットフォームに必要なPlexアプリケーションデータのディレクトリ全体を転送し、その方法で対応できる場合はタイムスタンプと所有権情報を保持してください。最終的なアプリケーション状態のコピーには、データベースの移動中に内容が変更されないよう、停止したPlexデータの転送を使用してください。メディアはパスマップに従って別途転送または再マウントしてください。大規模なライブラリでは、凍結前にメディアの初回コピーを実行し、書き込み元を停止した後に最終同期を行えます。アプリケーションデータベース自体は停止フェーズで扱う必要があります。

到着した内容を比較してください。ディレクトリの合計、ファイル数、マニフェストまたは整合性が重要なデータのチェックサムを使用し、コピーコマンドが100%に到達したことだけを根拠にしないでください。アプリデータに対象サービスアカウントの所有権を適用し、すべてのメディアルートで読み取りアクセスを確認してください。デスクトップは変更せず、必要であれば自動起動から切り離し、ロールバック用であることを明確に表示してください。復元した対象を評価している間、書き込みを再開してはなりません。

一時的なネットワーク識別情報でターゲットを起動します。想定したライブラリやサーバー識別情報が表示されない場合は、広範なスキャンやメタデータの再構築を開始する前に停止してください。コピーした状態、パスマップ、権限、プラットフォーム間の変換方針に戻って確認します。クリーンな再スキャンで最終的にポスターを復旧できる場合はありますが、それだけではユーザー履歴や元のサーバーとの関係が維持されたことの証明にはなりません。

すべてのクライアントをリダイレクトする前に新しいサーバーを検証する

使い慣れたサーバーアドレスを変更する前に、復元された状態を検証します。ライブラリの数と名前を比較し、既知のポスターやエディションが表示される項目を開き、いくつかの視聴位置を確認し、管理対象ユーザーの各クラスでサインインします。ターゲットホストと通常のクライアントからブラウズし、ローカルでライブラリが見えていることでネットワークやアカウントの障害が隠れないようにします。

測定済みの再生マトリックスを繰り返します。高ビットレートのローカルDirect Play、リモートストリーム、低画質を強制したトランスコード、一般的な字幕、現実的な最大同時セッション数をテストします。実際の配信モードを確認してリソース使用量を監視してください。1台のテレビで再生に成功しても、モバイルデータ通信中のスマートフォンや変換が必要なブラウザでの動作は検証できません。携帯通信での再生チェックを行えば、自宅ネットワークを再利用するのではなく、移行を実際のオフサイト環境でテストできます。結果は抽象的なハードウェア性能の約束ではなく、デスクトップのベースラインと比較してください。

次に、時間の経過後にのみ現れる依存関係をテストします。サーバーを再起動し、Plexより先にストレージがマウントされること、対話的なログインなしでサービスが起動すること、安定したLAN名が解決されること、意図した経路でリモートアクセスが復旧することを確認します。ネットワークアクセスを意図的に中断して復旧し、電源計画に含まれている場合は、制御されたシャットダウンも実行します。最初のセッションが機能していても、再起動後の失敗は移行の失敗です。

まず1台のクライアントだけを切り替えます。安定したアドレス、予約、ローカル名、または文書化されたクライアントパスをターゲットに移します。古いDNS情報、重複したポート転送、または自動起動する古いデスクトップサービスに注意してください。パイロットクライアントが正常に通過したら、残りのクライアントを少数のグループに分けて移行します。すべての段階で、書き込み可能なPlexの正式な書き込み元は必ず1つだけにします。

重要なテストに失敗した場合はターゲットを停止し、変更していないデスクトップに以前のネットワーク識別情報を戻して、記録した切り替え時刻から再開します。2つのデータベース間で書き込み先を切り替えないでください。失敗した要因（状態、パス、権限、クライアント互換性、ネットワーク、電源）を調査し、ソースが再び正式な書き込み元になった後で、新しい停止状態のコピーを作成します。

デスクトップ退役の判断基準を復元テストにする

切り替えに成功しただけでは、まだ復旧可能なサーバーとはいえません。失ってもよい視聴履歴やライブラリ作業の量に合わせたスケジュールで、Plexのアプリケーション状態をバックアップします。再入手が困難、または再作成に費用がかかるメディアは、独立したコピーで保護します。ディスクの冗長化によってドライブ障害後もサーバーの可用性を維持できる場合はありますが、削除、破損、盗難、サーバー全体の喪失に対して、RAIDはバックアップではありません。

アプリケーション状態のバックアップを、分離したフォルダー、仮想マシン、コンテナ、または予備ホストに復元します。代表的なメディアだけを接続し、一時的なIDで開始して、簡潔な受け入れテストを繰り返します。ライブラリが開くこと、既知の視聴状態が戻ること、管理対象ユーザーが適切なコンテンツを見られること、そしてダイレクト再生1件とトランスコード1件が完了することを確認します。コンテナ化したデプロイでは、分離された単一サービスの復元経路によって、正常な依存関係に触れず、Plexに集中して復旧できます。復旧時間、不足していた依存関係、使用したバックアップの正確な内容を記録します。

ベースラインが新しいうちに、拡張のトリガーを書き出しておきます。測定した継続的なセッションで余力が消費される場合は、トランスコード用コンピュートを追加または分割します。インポートやメンテナンス用に選んだ空き容量の下限にメディア層が達する前に、ストレージを拡張します。同時ダイレクト再生のビットレートがテスト済みのスループットに近づいたら、ネットワークを改善します。メンテナンス時間帯や成長率の結合を家庭で許容できなくなったら、ストレージとコンピュートを分離します。

復元に成功して初めて、古いデスクトップを消去、売却、または別用途に転用できます。それまでは、日付を明確に記録した状態で、電源を切った復旧経路として保持します。移行先を復元できない、ピーク時の再生要件を満たせない、または文書化されていないプラットフォーム間変換に依存している場合、移行は完了ではなく停止境界に達しています。

最終セットアップのルール

専用サーバーがPlex専用のホームになるのは、信頼できる状態を一つに定め、安定したメディアパス、測定済みの再生、クライアントアクセス、再起動時の挙動、バックアップ、分離環境での復元がすべて確認できてからです。バックアップが信頼できるのは、復元テストに成功した後だけです。それまではデスクトップをそのまま維持し、書き込みを行わない状態にしてください。パス変換やワークロード用の余力に不確実性が残る場合は、無理に切り替えず、移行を延期してその境界を解消します。