データを失わずに、PlexをARMとx86の間で移行できますか？
ARMからx86、またはx86からARMへのPlex移行は、盲目的なコピーではなく、状態の移行と機能互換性のテストとして扱いましょう。
データベースやメタデータは移行できても、バイナリ、メディア解析機能、ハードウェアアクセラレーション、パスの前提条件はプラットフォームによって異なる場合があります。新しいサーバーでライブラリ、視聴状況、メタデータ、再生、各種機能の確認に合格するまで、元のサーバーを保持してください。新しいサービスが起動したからといって、すぐに移行元を削除しないでください。
都合のよいファイル1つではなく、状態一式を移行する
Plexの状態には、単一のライブラリデータベース以上の情報が含まれています。1つのファイルだけをコピーすると、一部の履歴は保持できても、その他のメタデータやインデックスの再構築が必要になる場合があります。
ライブラリデータベースだけをコピーするのではなく、メタデータ、設定、視聴状態を含む完全なPlexサーバーデータディレクトリを移行すれば、安全に移行できます。
サーバーを停止した状態で、Plexの状態ディレクトリ全体を所有者情報とファイル構造を維持したままコピーしてください。新しいホストで完全な検証を終えるまで、移行元には変更を加えないでください。
メディアパスを維持するか、意図的に再マッピングする
データベースを移行できても、パス文字列までそのまま使えるとは限りません。マウントポイントやOSのパス規則が変わると、正しいレコードが利用できないメディアを指す可能性があります。
起動前にパスマップを作成し、以前のメディアルートと新しいメディアルートを比較してください。アーキテクチャの変更に伴ってOSも変わる場合は、パスの変換を独立した移行手順として扱いましょう。
大規模なスキャンを行う前に、各ライブラリから1項目ずつテストしてください。永続的なコンテナデータ配置でマウントを安定させると、アーキテクチャを切り替える際の変動要因を減らせます。
アーキテクチャ固有の機能を個別に検証する
ハードウェアトランスコード、一部の解析機能、ドライバーに依存する機能は、コアとなるライブラリの状態が正常でも異なる場合があります。ログインに成功しただけで機能の同等性を判断しないでください。
Plexの状態を共有しても、アーキテクチャ間で機能が完全に同じになるとは限りません。データベースとメディアパスの移行に成功した後でも、ARM/x86間の解析機能の違いが残る場合があります。
ダイレクトプレイ、トランスコード、HDR・字幕の経路、解析機能、リモートアクセスについてチェックリストを作成してください。新しいアーキテクチャでのみ発生する機能障害は、データ損失ではなく互換性の課題として扱うべきです。
通常利用で問題がないと確認できるまで、ロールバック可能な境界を維持する
新しいホストで遅れて問題が見つかった場合でも、以前のサーバーを復元できる状態であれば、移行は安全です。数分間ブラウジングできたからといって、移行元を廃止するには不十分です。
新しいホストで通常の1日分の利用、ライブラリの変更、再起動、バックアップと復元の確認を実施してください。新しいアーキテクチャによって保存状態が変化し、以前のホストで安全に再利用できない可能性がある場合は、稼働中のディレクトリを何度も切り替えるのではなく、移行前のコピーから復元してください。
新しいサーバーがこれらのテストに合格し、新しいバックアップの有効性を確認できてから、以前のホストを廃止してください。
おすすめ商品
サポートとヒント
もっと読む
Jellyfinは別のコンテナとGPUやアクセラレーターを安全に共有できますか？
GPUの共有には条件があります。デバイスが認識され、ドライバーが対応していることを確認してから、両方のワークロードを実行し、ソフトウェアフォールバックが発生していないか監視してください。
Jellyfinのエラーがクライアントとサーバーのどちらに起因するかを見分ける方法
Jellyfinのエラーが特定の1台のデバイスにだけ発生する場合はクライアント側に原因があり、同じ経路で複数のクライアントが失敗し、ログも一致する場合はサーバー側に原因があります。
Jellyfinのキャッシュと一時ストレージの設定方法
永続的なデータ、再構築可能なキャッシュ、一時的なトランスコード用ストレージを分離し、実際に再生テストを行って容量と権限を確認します。
