Jellyfinをデスクトップからオープンソースのメディアスタックに移行する方法

コンテナやNASを選ぶ前に、アプリケーションの状態、メディア、キャッシュ、バックアップ、ネットワークアクセスにそれぞれ明確な役割を割り当てて、Jellyfinを移行します。

通常、デスクトップではすべてのロールが1つのファイルシステムと1つの電源経路にまとめられています。オープンソースのメディアスタックでは、これらのロールが分離されています。そのため、最初のコンテナを起動する前に、各パス、UID/GID、サービスの依存関係、復元手順を割り当てておくことが移行の成功につながります。正常な再起動と実際のクライアントでのテストが完了するまで、ロールバック元としてデスクトップを残してください。

デスクトップをサービスロールに分ける

Jellyfinの設定とデータベース、メディアライブラリ、メタデータと画像キャッシュ、プラグイン、字幕キャッシュ、ユーザー、リバースプロキシやDNSの依存関係を洗い出します。それぞれを、永続的なアプリケーション状態、代替できないメディア、再構築可能なキャッシュ、バックアップコピー、復旧用メディアのいずれかに分類します。キャッシュをデータベースのようにコピーしたり、ミラーリングされたメディアボリュームを2つ目のバックアップとして扱ったりしないでください。

すべてのロールに担当者、移行先、アクセス経路、復元手順が割り当てられていれば、移行の範囲は明確です。ロールを個別に復元できない場合は、スタックの設計を見直すまでデスクトップ上に残してください。

イメージを選ぶ前に移行先の構成を決める

Jellyfin 用のサービスロールを1つ、設定とデータベース用の永続データボリュームを1つ、パスが変わらないメディアボリューム、そして別のバックアップ先を用意します。障害の影響を切り離す必要がある場合は、リバースプロキシ、監視、実験用サービスをそれぞれ独自のパスまたはネットワークに配置します。サードパーティ製の移行ツールからも、フォルダーをそのままコピーするのではなく、パスの変換とデータベースの扱いについて明確な計画が必要なことがわかります（パスを考慮したJellyfin移行のメモ）。

移行時にパスと権限を維持する

デスクトップ上のサービスを停止し、永続データのコピーを作成して、変換する前にコピーの内容を確認してください。可能な限り、移行先ではコンテナ内のメディアパスをデータベースに記録されたパスと一致させてください。コンテナのUID/GIDには、メディアを読み取り、必要なアプリケーションディレクトリに限って書き込めるユーザーまたはグループを設定してください。プラグインをインポートしたり自動化を追加したりする前に、ライブラリのスキャンを1回、ユーザーログインを1回テストしてください。

Jellyfinが対象のすべてのライブラリを読み取り、データベースに書き込み、パスマッピングを変えずに再起動できれば、判定はPASSです。権限の設定にメディアツリー全体への広範な書き込みアクセスが必要な場合は、先にデータの役割とアプリケーションの役割を分けてください。

Featured

ZimaCube 2 パーソナルクラウド ホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

再生、ユーザー、復旧を段階的に検証する

ローカルでのダイレクト再生、代表的なトランスコード、字幕、2つ目のユーザーアカウントをテストしてください。その後、対話型シェルからではなく、composeまたはデプロイ定義からスタックを停止して再作成します。アプリケーションデータのバックアップをクリーンなテスト場所に復元し、視聴済み状態、ユーザー、ライブラリパスが保持されているか、意図どおりに再構築されることを確認してください。

こうした確認を終えてから、リモートアクセスや追加サービスを導入してください。ZimaCube 2 AI NASのようなコンパクトなホストは、永続ストレージ、コンテナの余力、独立したバックアップ経路という中立的な要件が、すでにスタックに合致している場合に検討できます。

拡張と停止の境界を定める

ストレージ層、トランスコード対応のコンピュートノード、または独立したネットワーク機能を追加して拡張しましょう。新たなワークロードが増えるたびに、共有ボリュームを大きくするだけで解決しないでください。プラグイン、パス変換、ユーザー移行の動作が未確認なら、デスクトップ上のロールバック用コピーを残してください。元のデスクトップを起動しなくても、手順を文書化した再構築によって同じライブラリアクセスと再生結果が得られれば、スタックの準備は完了です。