JellyfinはARMとx86で同じデータを使って動作できますか？
通常は可能ですが、ARMからx86への移行は、すべてのJellyfinコンポーネントがアーキテクチャに依存しないことの証明ではなく、管理されたホスト移行として扱ってください。現在のJellyfinリリースでは、対象となるARM環境はARM64です。同様に、x86の移行先もサポートされている64ビットプラットフォームである必要があります。移行先で再起動と再生の確認が完了するまで、移行元はそのまま保持してください。
重要なのは運用上の境界です。永続状態をコピーする前に移行元を停止し、異なるホスト上の2つのJellyfinインスタンスが同じアクティブなデータディレクトリへ書き込む状態は絶対に避けてください。JellyfinはARM64からx86-64への移行を、特別にリスクゼロな移行経路として文書化していません。そのため、ロールバック用のコピーを保持し、FFmpegパッケージ、ハードウェアアクセラレーションのデバイスマッピング、ネイティブプラグインの依存関係、権限、ホストパスなど、プラットフォーム固有の要素は個別に再構築してください。
移行先のアーキテクチャが実際にサポートされていることを確認する
まず、移行先が現在サポートされている64ビット版Jellyfinプラットフォームであることを確認します。古いARMボード、32ビットOS、レガシーなx86マシンでも、Linuxが起動するというだけで利用可能だと判断しないでください。
Jellyfin 10.11では、armhfを含むARM32のサポートが正式に削除され、ARMプラットフォームではARM64 OSが必要になりました。移行元が古い32ビットARMビルドで動作している場合は、古いランタイムを現在の移行対象として扱うのではなく、まずサポート対象の64ビット移行先を計画してください。
x86では、使用するJellyfinのバージョン要件を満たす、サポート対象のx86-64ホストを使用してください。移行先が非公式パッケージ、サポート対象外のOS、または旧式のCPUに依存している場合は、永続状態を移動する前に、そのプラットフォームの問題を解決してください。
保存状態はポータブル、デプロイはプラットフォーム固有として扱う
標準的なJellyfinデプロイでは、設定ファイルやメタデータファイルとともに、データベースへサーバーの永続状態が保存されます。SQLiteを使用するインストールでは、ディスク上のデータベース形式はプロセッサアーキテクチャ間で移植できるよう設計されているため、CPUファミリーだけを理由に、移行前にデータベースをバイト変換する必要はありません。
SQLiteは、そのファイル形式をクロスプラットフォームのデータベース形式として文書化しており、32ビット／64ビットシステム間やエンディアンの違いをまたぐ移植性も含まれます。これは移行におけるデータベース形式の互換性を裏付けますが、すべてのJellyfinプラグイン、外部実行ファイル、ドライバー、デプロイ固有のパスが変更なしに維持されることを保証するものではありません。
区別を明確にしてください。保存されたレコードがポータブルであることは、あくまで1つの層にすぎません。Jellyfinのバージョン互換性、データと設定の完全なカバー範囲、メディアパスの一貫性、プラグインの依存関係、権限、ハードウェアデバイスへのアクセスが、移行先が移行元と同じように動作するかどうかを左右します。
アクティブな状態を移動する前にJellyfinを停止する
管理されたアーキテクチャ移行を行う場合は、移行用コピーを作成する前に移行元のJellyfinプロセスをシャットダウンしてください。これにより、ファイルのコピー中にアクティブなデータベースや先行書き込み状態が変更されるのを防ぎ、一貫したロールバックポイントを確保できます。
jellyfin.dbだけを選ぶのではなく、データと設定の範囲全体をコピーしてください。不完全なコピーでは、ユーザー情報は保持できても、移行先が必要とする設定、プラグイン、メタデータ、その他の状態が失われる可能性があります。
複数コピーによるバックアップ計画で使用するのと同じ保護モデルをここでも適用してください。移行先で実際の復元と再生の検証が完了するまで、移行元はそのまま保持します。
新しいホストでアーキテクチャ固有の要素を再構築する
移行先のネイティブJellyfinパッケージをインストールするか、正しいマルチアーキテクチャ対応コンテナイメージを使用してください。古いアーキテクチャのバイナリをコピーするのではなく、GPUデバイスのマッピング、グループ権限、FFmpegパッケージ、ホスト固有のパスを再構成します。
初回起動後にプラグインを確認してください。ネイティブライブラリ、同梱バイナリ、外部実行ファイルに依存するプラグインは、新しいアーキテクチャに対応したビルドが必要になる場合があります。起動を妨げる疑わしいプラグインは、最初の検証中は無効にし、互換性を確認してから再び追加してください。
ホスト間でメディアパスが異なる場合は、可能であればマウントを使用して同じパスを維持してください。それが難しい場合は、Jellyfinの内部データベースレコードを手動で編集するのではなく、サポートされたパス移行を計画してください。
移行元を再利用する前に移行を検証する
移行先のインスタンスだけを起動し、ユーザー、ライブラリ、視聴状況、アートワーク、スケジュール済みタスク、さらにDirect Playを1件と、必要なトランスコードを1件確認してください。ログを確認し、ネイティブライブラリの不足、権限エラー、古いホストを参照したままのパスがないかを確認します。
移行先を2回再起動し、再生テストを繰り返して、成功が一時的な起動時のものではなく永続的なものであることを確認してください。移行先が失敗した場合は、移行先を停止して移行用コピーから復元するか、変更していない移行元に戻してください。両方のインスタンスに同じ状態を書き込ませてはいけません。
新しいホストが再起動と通常の家庭内利用に耐えられることを確認して、初めて移行は完了です。古いマシンを利用可能な状態で残したい場合は、別に復元したコピーを用意するか、電源を切ったままにしてください。ARMサーバーとx86サーバーの間で、1つの稼働中のJellyfinデータディレクトリを共有ストレージとして使用しないでください。
おすすめ商品
サポートとヒント
もっと読む
Jellyfinでは共有アカウントを1つ使うべきか、それとも家庭内で別々のアカウントを使うべきか？
必要な本人確認、アクセス、ペアレンタルコントロール、復旧の境界に応じて、Jellyfinの家庭用アカウントを選択してください。
作業完了後もJellyfinのメモリ使用量が高いままなのはなぜですか？
Jellyfinプロセスの増加とLinuxキャッシュを切り分け、メモリ使用量が増え続けるか、実際にメモリ圧迫が発生した場合にのみ調査してください。
Jellyfinのストレージ構成が復旧リスクになりつつある兆候
Jellyfinのストレージの役割を監査し、稼働中の状態をバックアップや再構築可能なデータから分離したうえで、復元によってその構成を検証する。
