新しいネットワークに移行した後、Jellyfin環境を再構築する方法

エヴァ・ウォン

IceWhale author

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

How to Rebuild a Jellyfin Setup After Moving to a New Network - Zima Store Online

ネットワーク移行後にJellyfinを再構築する場合は、まずローカルサービスの経路を復元し、その後、ストレージのマウント、ID、DNS、リモートアクセスを個別の関門として検証します。

新しいルーター、サブネット、VLAN、またはDNSドメインによって、正常なJellyfinデータベースでも壊れているように見えることがあります。これは、クライアント、マウント、リバースプロキシが同じ経路を共有しなくなるためです。以前のネットワーク設定のメモとアプリケーションデータのコピーを保管してください。目標は、クライアントからサービス、メディアまでの既知の経路を確立し、ネットワーク自体が失敗層であり、Jellyfinが原因ではない場合に明確に停止できる状態にすることです。

変更前に以前の経路を記録する

サーバーのアドレス、ホスト名、サブネット、ゲートウェイ、DNS名、メディアのマウントパス、リバースプロキシの転送先、証明書名、ファイアウォールまたはポート転送のルールを記録します。ローカルストリーミングとリモートストリーミングを分けて考えてください。以前のホストがまだ利用できる場合は、新しいアドレスを割り当てる前にJellyfinの設定をエクスポートし、ユーザーとライブラリの一覧を作成します。

これにより、再構築の基準ができます。ユーザーがサービスにアクセスし、サービスがデータベースとメディアにアクセスし、バックアップが保存先に到達できる状態です。パブリックポートや新しいプロキシルールから始めないでください。

安定したアドレスでローカルサービスを復元する

サーバーにDHCP予約または固定アドレスを設定し、同じLANからJellyfinのWebインターフェースが開くことを確認します。サービスのバインドアドレスとホストのファイアウォールを確認し、DNSを変更する前にローカルクライアントでテストします。アプリは起動するのにライブラリが空の場合は、データベースを再構築せず、ストレージパスを調べてください。

Jellyfinの移行ガイダンスでは、内部データがパスに依存し、コンテナのパスが記録したメディアの場所と一致している必要があると説明されています（パス依存の移行ガイダンス）。パスの不一致はメタデータの障害ではなく、トポロジーの障害として扱ってください。

DNSの前にマウントと権限を再接続する

メディアとバックアップのボリュームを安定したパスにマウントし、Jellyfinのサービスアカウントで読み取りアクセスをテストします。各ライブラリから1ファイルを確認し、アプリケーションデータディレクトリに1回書き込めることを確認してください。キャッシュとダウンロードしたアートワークは再構築可能なストレージに置き、ユーザーメディア、データベース、バックアップは保護された役割のストレージに保管します。

再起動後にJellyfinの起動前にマウントが再作成され、ライブラリスキャンでファイル欠落の警告が出なければPASSです。マウントが対話的なログインに依存している場合は、続行する前に起動順序を修正してください。

-15% OFF

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

Single board computer zimaboard2

この順序でID、DNS、リモートアクセスを再構築する

ローカル再生が機能したら、ホスト名と内部DNSレコードを復元します。IPアドレスではなく名前を使ってクライアントをテストし、その後、自宅の外部からリバースプロキシまたはVPNを検証します。認証と認可をルーティングから分離してください。ログイン失敗は、新しいポート転送が間違っている証拠ではありません。

実際に使用するクライアント構成で、直接再生を1回、トランスコードを1回実行します。確認できたエンドポイント、再生モード、失敗箇所を記録してください。コミュニティの移行事例は、パスとネットワークに関する前提を比較する際に役立ちますが、そのハードウェアやルーター設定を一般化しないでください（移行事例）。

ロールバックと拡張を明確にしておく

ローカル再生、ユーザーアクセス、リモートルーティング、復元のすべてに合格するまで、以前のDNSレコード、設定バックアップ、過去のネットワークメモを保管します。共有経路の性能が低下した場合にのみ、管理用の別VLANや2つ目のネットワークインターフェースなど、専用の経路を追加して拡張してください。サーバーが安定したアドレス、永続的なマウント、またはテスト済みの復旧経路を確保できない場合は、再構築を中止します。こうした基盤の欠如は、クライアントをいくら再設定しても解決できません。