成長中のJellyfin環境にはどれくらいのストレージ容量が必要？

現在のライブラリに加え、予測される増加分と運用上の余裕を確保できる十分な使用可能メディア容量を購入し、Jellyfinのアプリデータとバックアップは別のストレージ要件としてサイジングしましょう。

ドライブ台数ではなく容量計算から始める

シンプルな計画モデルを使いましょう。使用可能なメディア容量の目標 = 現在のライブラリ + 計画期間中の予想追加量 + 作業用の空き容量です。最初の項目はストレージから測定し、追加量は過去6〜12か月の実績から見積もり、ドライブを追加または交換する頻度に合った計画期間を選びます。

このモデルは「ユーザー1人あたりX TB」と考えるより適切です。ユーザーのストレージ消費量は一定の割合で増えるわけではありません。解像度、コーデックの効率、リマックスか圧縮ファイルか、ホームビデオの取り込み、保存方針によって、年間の増加量は世帯人数よりはるかに大きく変わる可能性があります。

実績がない場合は、控えめに始めて数か月後に再測定しましょう。目的は完璧な5年予測ではありません。すでに容量不足になる購入を避けつつ、使う根拠のない容量に大きな割増料金を支払わないことです。

メディア容量とJellyfinのアプリデータ容量を分けて考える

Jellyfin自体には、オペレーティングシステム、データベース、メタデータ、キャッシュ、生成画像、一時トランスコードデータのための容量が必要です。これらのファイルは動画ライブラリよりはるかに小さい一方で、異なる性能要件があります。

Jellyfin公式のハードウェアガイドでは、OS、Jellyfinのファイル、トランスコードキャッシュ用のSSD容量として、おおよそ100 GBを計画時の目安として推奨しています。ただし、ソースファイルが大きい場合や同時トランスコードが発生する場合は、一時領域の必要量が増える可能性も指摘しています。

このSSD容量をメディアライブラリの見積もりに使わないでください。メディア容量は数TBに及ぶ一方、アプリデータは低レイテンシのストレージから恩恵を受けます。すべてを収める非常に大容量のSSDを1台購入することと、手頃な容量の高速ストレージ層と経済的な大容量ストレージを組み合わせることは、通常は別の判断です。

将来の映画だけでなく運用のための余裕も加える

空き容量は運用容量です。インポート、ファイル移動、一時コピー、ファイルシステムのメンテナンス、パリティ再構築、スナップショット、トランスコードセグメントは、プールがほぼ満杯になるとすべて難しくなります。ストレージ技術とメンテナンス手順に合った余裕を残し、使用率100%での運用を計画しないようにしましょう。

増加は一気に発生することもあります。カメラのアーカイブ、家族動画のデジタル化、コレクションの一括移行では、通常の月間メディア取得量を週末だけで上回るデータが追加される可能性があります。そのようなプロジェクトが分かっている場合は、一般的な割合の中に隠さず、明示的に含めてください。

代替できない個人メディアについて、ZimaSpaceのホームメディアサーバーガイドでは、アプリのキャッシュやインポート領域に依存せず、独立してバックアップできる分かりやすいメディアフォルダーに家族動画を保存することを推奨しています。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

冗長性をバックアップ容量として数えない

パリティ、ミラーリング、RAIDはドライブ故障後の可用性を高められますが、削除、破損、ランサムウェア、筐体の故障に備えた独立した復旧コピーを作るものではありません。バックアップ容量はプライマリアレイのディスク台数ではなく、復旧が必要なデータ量を基準に決めてください。

置き換え可能なメディアファイルすべてについて、必ずしも完全な2次コピーが必要とは限りません。ライブラリを分類しましょう。代替できない家族動画や整理した個人コンテンツには完全バックアップが適している場合がありますが、代替可能なメディアには別の方針を採用できます。Jellyfinのアプリ状態は小さいため、個別に頻繁なバックアップを取ることは通常、現実的です。

Jellyfinのバックアップ機能では、データベースと、メタデータ関連で選択したデータを保護できます。ただし、保存先にも十分な空き容量が必要であり、稼働中のアプリデータボリュームとは異なる障害ドメインに配置する必要があります。

大容量の製品があるからではなく、増加のきっかけが来たら容量をアップグレードする

予測される使用可能な空き容量が、次のメンテナンス時期までに必要な量を下回る場合、または現在の筐体に次に適切なドライブを追加できない場合に、アップグレードが正当化されます。これは容量上のトリガーであり、性能上のトリガーではありません。

現在のプールに測定済みの余裕が何年分もあるなら、より大きな筐体を購入したり、正常なドライブを早期に交換したりしても、日常的なメリットはほとんどないかもしれません。一方、すべてのベイが埋まっていて年間の増加量が予測できる場合は、今日のTB単価を最安にすることより、拡張の柔軟性のほうが価値を持つ可能性があります。

ZimaCube 2のようなマルチベイプラットフォームが適しているのは、測定した増加量、バックアップ構成、または追加サービスによって、そのストレージ形態が必要な場合に限られます。まず使用可能容量と復旧コピーを計算する代わりにはなりません。

購入を決める前にこのチェックを行う

ストレージを購入する前に、現在のメディア容量、年間純増量、計画期間、最低限確保する空き容量、独立したバックアップが必要なデータ量という5つの数字を記録します。そのうえで、選択した冗長化方式の後にどれだけの使用可能容量が残るかを確認してください。

また、ドライブインターフェース、ベイ数、ファイルシステムまたはプールの拡張動作、騒音、消費電力、交換手順も確認しましょう。TB単価は安くても、実際のサーバーで追加、冷却、交換がしにくいドライブは、所有コストを高くする可能性があります。

計画期間を運用上の余裕と現実的なバックアップ手段付きでカバーできたら、そこで止めましょう。それ以上の容量は、Jellyfinの性能向上ではなく、任意の保険にすぎません。