Jellyfinとメディア間の依存関係を最小限にすることを優先するなら、通常はローカルストレージのほうが信頼性に優れています。一方、ストレージ管理の独立性、容量拡張、コンピュート環境の交換を重視するなら、ネットワークストレージのほうが信頼性に優れています。多くのホームサーバーにとって最適な答えはハイブリッド構成です。Jellyfinのデータベースとアクティブなアプリケーション状態はローカルに保持し、大容量のメディアは適切に管理されたNAS共有に置きます。
このハイブリッド構成が重要なのは、「ローカルかネットワークか」という区分に、実は異なる2種類のデータ役割が隠れているからです。Jellyfinのアプリケーションファイルは小さなランダムアクセスを頻繁に実行します。一方、メディアファイルの読み取りは主に大容量のシーケンシャルアクセスであり、異なるストレージ構成にも対応できます。
依存関係の少なさではローカルストレージが優位
ローカルSATA、NVMe、または直接接続ディスクを使用すれば、Jellyfinはスイッチ、NAS、リモートマウント、名前解決、ネットワーク認証を待たずに起動し、データを読み取れます。同時に正常でなければならないコンポーネントが少なく、トラブルシューティングも通常は1台のホストから始められます。
その代わり、構成が密結合になります。データ配置を慎重に分離しない限り、コンピュート環境の交換、OSの再インストール、ストレージメンテナンスはすべて同じ物理システムを中心に行うことになります。ネットワーク経由でないからといって、ローカルディスクが自動的に保護されるわけではありません。
コンピュート環境と容量のライフサイクルを分離したい場合はネットワークストレージが優位
NASを使用すれば、メディアプールを移動せずにJellyfinのコンピュートノードを再構築またはアップグレードできます。また、複数のデバイスやサービスに対して、複数ドライブの冗長性、スナップショット、共有アクセス、容量拡張を一元化できます。
ただし、この分離が役立つのは、ネットワークストレージが安定してマウントされ続ける場合に限られます。Jellyfinのストレージに関するガイダンスでは、SMBまたはNFSストレージをサーバーOSに直接マウントするよう推奨しています。また、メディアストレージが不適切なタイミングで利用できないと、メンテナンスタスクによってライブラリ項目が削除される可能性があると警告しています。
メディアがリモートにあってもデータベースはローカルに保持する
これは、この比較で最も重要な誤った二分法です。Jellyfinのデータベースは、メディアと同じ場所に置く必要はありません。Jellyfinのストレージに関するガイダンスでは、データベースをネットワークストレージではなくローカルに保持することを明確に推奨しつつ、メディアファイルはマウントされた共有から読み込めるとしています。
ローカルのSSD上にアプリケーションデータを置くことで、遅延を抑え、データベースの整合性をネットワーク経路から切り離せます。リモートメディアには、NASが得意とする保護された容量の提供と、シーケンシャルなファイル配信を任せられます。ZimaSpaceのストレージの役割に関する比較でも、アプリケーションのデータベースやメタデータと、大容量メディアストレージを分けて考えています。
ディスク速度の数値ではなく障害ドメインを比較する
ローカルストレージでは、ホスト、コントローラー、ケーブル、電源、ファイルシステム、またはディスク経路に障害が発生すると停止します。ネットワークストレージでは、スイッチ、NIC、配線、マウント、NASのOS、認証、リモートプールの可用性が依存関係として加わります。依存関係の範囲は広がりますが、専用NASは、場当たり的なローカル構成よりも優れたディスク監視、冗長性、スナップショット、交換手順を提供できる場合があります。
どの障害に耐える必要があるのかを考えてください。コンピュートノードを再インストールしてもメディアプールに影響を与えたくないなら、ネットワークによる分離には信頼性上の価値があります。家庭に小規模なライブラリしかなく、追加されるネットワークコンポーネントを管理できないのであれば、ローカルストレージのほうがシンプルで信頼できる構成になる可能性があります。
可用性とマウント動作を確認してからスループットを考える
正常なHDDやNAS接続は、通常のメディアストリームのビットレートを容易に上回るため、ベンチマーク速度が高いからといって信頼性が自動的に向上するわけではありません。最も混雑する時間帯の合計読み取り量を測定し、同じディスクやネットワークを共有するバックアップ、スキャン、ファイル転送も含めて考えてください。
NAS上のDirect Playファイルが途中で止まる場合は、同じファイルを信頼できることが確認されたローカルストレージにコピーして再テストしてください。ローカルでは再生でき、ネットワーク経由では失敗するなら、問題はリモート経路にある可能性があります。両方で失敗する場合は、ストレージ構成ではなく、クライアント、メディア、またはサーバー側の処理に焦点を戻します。
必要な復旧方法に応じてローカル、ネットワーク、ハイブリッドを選ぶ
ローカルストレージを選ぶのは、ライブラリが小規模で、ホストに十分な直接接続ドライブ経路があり、独立した拡張性よりも依存関係の最小化を重視する場合です。ネットワークストレージを選ぶのは、専用NASがすでに容量とデータ保護の役割を担っており、メディアを移動せずにコンピュート環境を交換したい場合です。
ハイブリッド構成を選ぶのは、Jellyfinのデータベース、メタデータ、キャッシュ、トランスコード状態にはローカルSSDを使い、大容量メディアにはネットワークストレージを使い、さらに稼働中のストレージシステムとは別にバックアップを用意したい場合です。メディアプール自体をどのように接続するかが次の課題なら、DASとNASのストレージ比較が参考になります。
信頼性は、構成の呼び名ではなく、復元テストと障害テストによって証明されます。コンピュートノードを再起動し、一時的にメディア共有を利用できない状態にし、Jellyfinの状態をクリーンなパスに復元して、その構成が意図したとおりに障害から復旧できることを確認してください。
製品比較
もっと読む

JellyfinメディアボリュームにはZFS、Btrfs、ext4のどれが適している?
リカバリーモデルに応じてJellyfinのメディアファイルシステムを選択しましょう。プールの整合性を重視するならZFS、LinuxネイティブのCoWならBtrfs、運用の複雑さを抑えるならext4がおすすめです。

Jellyfin内蔵バックアップとファイルレベルバックアップ:どちらを使うべき?
便利なアプリ状態の復元にはJellyfin内蔵のバックアップを使用し、ホストやデプロイメントのより広範な状態も復元する必要がある場合は、停止した状態でファイルレベルのバックアップを使用してください。

KodiとJellyfinの併用 vs スタンドアロンのJellyfinクライアント:どちらが適している?
クライアント側の状態管理を重視するカスタマイズ可能なテレビ中心のワークフローにはKodiを、よりシンプルで複数デバイスに対応したサーバー主導の利用にはスタンドアロンのJellyfinクライアントを選択してください。

