Jellyfin向けのSSD、HDD、バックアップ容量の選び方

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

Jellyfinのストレージは、高速なアプリケーション用・スクラッチ領域、経済的なメディア容量、独立した復旧用容量という、3つの異なる容量問題として考えるべきです。1台の非常に大容量なドライブを購入して「Jellyfinストレージ」と呼ぶだけでは、パフォーマンス、増加量、復旧の予測が難しくなります。

まず現在のライブラリと実測したJellyfinデータを基準にし、最大の一時作業ピークを加え、利用期間中のメディア増加量を見積もります。そのうえで、稼働中の障害ドメイン外にバックアップ世代を確保できるよう容量を決めます。ドライブのラベルに印刷された生の数値ではなく、冗長化後の使用可能容量を使って計算してください。

アプリデータと一時ピーク用のSSD容量を決める

Jellyfinのデータベース、メタデータ、アートワーク、ログなどのアプリケーションファイルはランダムI/Oを発生させるため、低レイテンシーのストレージが有利です。トランスコードキャッシュには別の一時容量が必要で、同時変換中に急増することがあります。

現在のJellyfinストレージに関する指針では、中規模のデータベースが数十GBまで増加することがあり、トランスコードフォルダーが変換中のソースメディア容量に一時的に近づく場合があるとされています。そのため、現在データベースが小さくても、容量の小さな起動用SSDはリスクがあります。

現在のアプリデータ容量と、実際に発生した最大のトランスコードピークを測定します。SSDを公称容量いっぱいまで使うのではなく、更新、一時ファイル、増加分のための空き容量を加えてください。

メディアの増加量と使用可能な冗長化後容量からHDD容量を決める

大量のメディアには通常、容量とシーケンシャルスループットが適しています。現在のメディア容量、現実的な年間追加量、ストレージ構成を再構築するまでの想定年数を計算します。

次に、ミラーリングまたはパリティのオーバーヘッド後に使用可能な容量へ、予測した目標容量を換算します。12TBのドライブ2台をミラーリングしても、メディア用に使用できる容量は24TBにはなりません。スナップショットや予約済み空き容量によって、安全な実用容量はさらに減る場合があります。

ZimaSpaceによるメディアファイル以外でJellyfinが使用するストレージの分析からも、永続的なアプリデータ、生成アセット、一時トランスコード、ソースメディアは同じ曲線で増加するわけではないことが分かります。

標準でSSDの速度を選ぶのではなく、ワークロードに合わせてメディア容量を購入する

大容量の映画やエピソードでは、通常、SSDのレイテンシーよりシーケンシャルスループットのほうが重要です。複数の独立したストリームや同時スキャンによってシーク負荷が増えることはありますが、健全なHDDプールでも相当なメディア帯域幅を提供できます。

継続的なサーバー書き込みと予測可能な再構築動作に適したドライブモデルと記録技術を選びます。静音性、物理サイズ、消費電力、または実測した混合I/O性能によって正当化できる場合に限り、バルクメディアをSSDへ移行してください。そうでなければ、SSDのテラバイトあたりの大幅に高いコストに見合わない可能性があります。

メディア層は、SSDは常に高速だという一般論ではなく、合計ビットレートとメンテナンス作業を組み合わせて選ぶべきです。

バックアップ容量はRAID容量とは別に計算する

RAID、ミラーリング、ZFSの冗長化、Btrfsのミラーリングは、一部のドライブ障害後の可用性を高めます。しかし、削除したメタデータ、破損したアプリケーション状態、不適切なアップグレード、ランサムウェアによる被害、管理者のミスを保護するものではありません。

3-2-1モデルでは、異なるメディアに複数のコピーを作成し、少なくとも1つをオフサイトに保管することが推奨されています。Jellyfinでは、代替できないメディア、再取得可能なリッピング済みメディア、アプリケーション状態に対して、同じ深度のバックアップが必要かどうかを個別に判断してください。

アプリケーション状態のバックアップは、数TB規模のメディアアーカイブと比べて小容量です。そのため、完全なメディアライブラリに別のバックアップ戦略を採用する場合でも、ユーザー情報、視聴進捗、メタデータ、設定を頻繁に保護することは経済的です。

ドライブを注文する前に容量ワークシートを使う

ストレージの役割 測定する入力値 容量の判断
SSDアプリデータ 現在のデータ容量+増加分 永続データ用の低レイテンシー余裕
SSDトランスコード用スクラッチ 最大ファイル容量×同時変換数 一時ピーク+空き容量の余裕
HDDメディア 現在のライブラリ+年間増加量 冗長化後の使用可能容量
ローカルバックアップ 保護対象範囲×保持世代数 独立した復元用容量
オフサイトバックアップ 代替できないデータの範囲+保持期間 個別の災害復旧用コピー

3つすべての層を同じ増加率で購入しないでください。トリックプレイを有効にしたとき、バックアップ保持期間を変更したとき、4Kリマックスを追加したとき、または主にダイレクトプレイを使う構成から頻繁なトランスコードへ移行したときは、再計算します。

よくある質問

Jellyfinのメディアライブラリ全体をSSDに置くべきですか?

通常は必要ありません。SSDは、Jellyfinのアプリケーションデータや一時的なランダムI/O処理に最も効果的です。合計スループットとシーク動作が実際のストリーム構成を満たすなら、大容量のシーケンシャルメディア読み出しにはHDDのほうが費用対効果に優れています。

Jellyfinにはどれだけのバックアップ容量が必要ですか?

何を保護し、何個の復旧ポイントを保持するかによって異なります。アプリケーション状態のバックアップをメディアアーカイブとは別に容量設計し、ストレージプールの生容量をそのままコピーするのではなく、保護対象の範囲と現実的な保持期間に基づいて計算してください。

購入ガイド

もっと読む

NAS購入前の家族写真移行リスクガイド
Oct 03, 2026

NAS購入前の家族写真移行リスクガイド

エクスポート後もオリジナルとメタデータが保持され、重複ファイルが分類され、ステージング領域に収まり、ロールバックによってソースがそのまま維持されるなら、写真用NASを購入する。

パスワード保管庫サーバーの可用性リスクガイド
Oct 03, 2026

パスワード保管庫サーバーの可用性リスクガイド

キャッシュ済みアクセス、独立した復旧用認証情報、復元テスト、そして別の運用担当者を用意して、障害による締め出しを防げる場合にのみ、パスワード保管庫をセルフホストしてください。

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.