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

エヴァ・ウォン

IceWhale author

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

How to Migrate Jellyfin From a Desktop to an Open-Source Media Stack - Zima Store Online

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

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

デスクトップをサービスの役割に分解する

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

すべての役割に担当先、保存先、アクセス経路、復元手順が割り当てられた時点で、移行の境界は明確になります。ある役割を単独で復元できない場合は、スタック設計を見直すまでデスクトップ上に保持してください。

イメージを選ぶ前にターゲットの構成を決める

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

移行中もパスと権限を維持する

デスクトップのサービスを停止し、永続データのコピーを作成して、変換する前にコピーを検証します。ターゲット側では、可能な限り、コンテナ内のメディアパスをデータベースに記録されたパスと同一に保ちます。コンテナのUID/GIDには、メディアを読み取れ、必要なアプリケーションディレクトリにのみ書き込める主体を設定します。プラグインをインポートしたり自動化を追加したりする前に、1つのライブラリのスキャンと1人のユーザーのログインをテストします。

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

-15% OFF

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

Single board computer zimaboard2

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

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

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

拡張と停止の境界を設定する

ストレージ層、トランスコード対応のコンピュートノード、または独立したネットワーク役割を追加して拡張します。新しいワークロードが増えるたびに、1つの共有ボリュームを拡張して解決しようとしないでください。プラグイン、パス変換、ユーザー移行が未検証の場合は、デスクトップのロールバック用コピーを保持します。元のデスクトップを稼働させなくても、文書化された再構築によって同じライブラリアクセスと再生結果が得られれば、スタックの準備は完了です。