メディアのメタデータはSSDに保存すべきか、それともライブラリと一緒に保存すべきか？

エヴァ・ウォン

IceWhale author

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

Should You Keep Media Metadata on SSD or With the Library? - Zima Store Online

メディアサーバーのデータベースとアクティブキャッシュはSSDに置き、移行性が重要な場合は、移植可能なNFOファイルと選択したアートワークをライブラリと一緒に保存します。

「メタデータ」には、アプリケーションデータベース、ユーザー状態、インデックス、キャッシュ、ダウンロードしたアートワーク、チャプター画像、トリックプレイプレビュー、NFOサイドカー、手動で整理した画像など、複数の異なる要素が含まれます。これらをすべて1か所に置くと、不要なHDDの遅延が発生したり、移植性が低下したりします。一般的なホームメディアサーバーでは、バックアップと復旧の境界を文書化した分割レイアウトが最も適しています。

ドライブを選ぶ前にメタデータを分類する

アプリケーションデータベース、設定、ユーザーアカウント、視聴履歴、インデックス、キャッシュ、サムネイル、ポスター、背景画像、NFOファイル、字幕、プラグインデータを一覧化します。各項目を、信頼できる唯一のデータ、移植可能、再構築可能、一時的のいずれかに分類します。

アプリケーションデータベースとユーザー状態は通常、サーバー固有で頻繁に変更されます。メディアと同じ場所に保存されたNFOファイルとアートワークは、互換性のある別のライブラリでも読み取れるファイル単位の付属データです。一方、キャッシュや生成されたサムネイルは削除しても問題ない場合があります。

フォルダー名全体だけを見て保存場所を決めないでください。「metadata」という名前のディレクトリには、かけがえのない手動編集データと、簡単に再生成できる画像キャッシュの両方が含まれている可能性があります。そのため、内容ごとに異なるバックアップと配置のルールが必要です。

データベース、インデックス、アクティブキャッシュはSSDに置く

データベースクエリ、ライブラリの閲覧、検索、ユーザー状態の更新、サムネイルの参照では、多数の小さな読み書きが発生します。SSDはこれらの処理の遅延を抑え、連続的なメディア処理の負荷から切り離します。

高速ストレージを使っても、安全性の低いファイルシステムや容量不足のボリュームが問題にならないわけではありません。Jellyfinのある問題報告では、通常の使用中にデータベースのロックアップとインターフェースの応答停止が発生しており、アプリケーションデータベースが稼働上の重要な依存要素であり、使い捨てのキャッシュではないことが分かります。

十分な空き容量、スナップショット、バックアップを備えたSSDに、永続的なアプリデータ一式を配置します。アプリケーションがロックと遅延の特性を明示的にサポートしていない限り、アクティブなデータベースをネットワーク共有に置くことは避けてください。

必要に応じて、移植可能なNFOファイルと整理したアートワークをメディアと一緒に保管する

サイドカーNFOファイル、ローカルポスター、エディションラベル、手動で選択したアートワークがあれば、別のインスタンスでライブラリを再構築しやすくなります。アプリケーションデータベースを失っても、これらは映画フォルダー内で確認できます。

すべてのバージョンやスキャナーで移植性が保証されるわけではありません。Jellyfinの移行に関する報告では、既存のNFOファイルが移動後に無視され、上書きされたと説明されています。そのため、サイドカーだけを唯一の復旧手段として頼る前に、テストインポートを実施する必要があります。

アプリケーションが一貫して読み取れ、保持する意図のあるメタデータだけを保存します。手動で整理したファイルはバックアップし、管理されたテストなしに自動プロバイダーが上書きしないようにしてください。

-15% OFF

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

Single board computer zimaboard2

読み取り専用ライブラリと権限の境界を守る

読み取り専用のメディアマウントは、アプリケーションによるソースファイルの誤変更を防ぎます。しかし同時に、サーバーがライブラリの隣にNFOファイル、アートワーク、コレクション、ローカルプレビューを書き込むこともできなくなります。

あるJellyfinの問題では、アプリケーション設定をSSD上で書き込み可能にしていたにもかかわらず、読み取り専用のメディアファイルシステムによってコレクションの作成に失敗しました。この事例は、書き込み場所がメタデータ機能に影響する理由を示しています。

ソースの不変性が重要な場合は、メディアを読み取り専用にし、アプリケーションが所有するメタデータをSSDボリュームに保存します。ローカルサイドカーを復旧計画の一部として意図的に使用する場合にのみ、ライブラリへの書き込みアクセスを許可し、そのアクセスはサービスのIDに限定してください。

再構築可能なプレビューデータを重要な状態から分離する

トリックプレイ画像、チャプターサムネイル、抽出したプレビューグリッド、一時キャッシュは、コアデータベースよりはるかに大きくなることがあります。また、多くの場合に再生成できるため、バックアップの価値も異なります。

Jellyfinには、アートワークとトリックプレイ画像をメディアと同じ場所に保存するオプションがあり、一部のレイアウトでは可視性と移行性が向上します。そのインターフェースのソースでは、ローカルアートワークとトリックプレイの保存場所が、すべてのメタデータに共通する1つの保存先ではなく、個別の選択肢として説明されています。

プレビューの増加が大きい場合は、専用のキャッシュまたはメタデータ用サブボリュームを使用します。データベースと手動メタデータは、再構築可能なサムネイルよりも頻繁にバックアップし、復旧時に削除してよいフォルダーを文書化してください。

復旧と移行の要件に合わせてレイアウトを選ぶ

1台のサーバーがライブラリを管理し、メディアマウントを読み取り専用に保ちたい場合、またファイル単位の移植性よりも高速な閲覧を重視する場合は、アプリメタデータをSSDだけに保存します。整理したメタデータをファイルと一緒に移動させたい場合や、複数の互換ツールでライブラリを共有する場合は、ローカルNFOとアートワークを使用します。

通常は分割レイアウトが最適な境界を提供します。データベース、ユーザー、インデックス、アクティブキャッシュはSSDに置き、ソースメディアは大容量ストレージに保存します。選択したNFOファイルと整理したアートワークはメディアの隣に置き、大容量の再構築可能なプレビューは、別途容量を設定したキャッシュまたはサポート対象のローカルパスに保存します。

データの種類	推奨保存場所	バックアップの優先度
アプリデータベース、ユーザー、視聴状態	SSD上のアプリボリューム	高
インデックスとアクティブキャッシュ	SSDまたは専用キャッシュ	低〜中
整理したNFOとアートワーク	移植性が重要な場合はメディアの隣	手動編集済みの場合は高
トリックプレイとチャプター画像	容量を確保したキャッシュまたはサポート対象のローカルパス	通常は再構築可能
映画と番組のソースファイル	大容量ストレージ	代替可能性に基づく

アプリケーションとメタデータのワークロードに適したNASドライブの選び方に関するZimaSpaceのガイドでは、この分割方法に必要なストレージ性能の背景を説明しています。

バックアップと復元のテストでレイアウトを検証する

メディアサーバーを停止し、SSD上のアプリボリュームと、ライブラリに保存されているサイドカーメタデータをバックアップします。同じコンテナパスと権限を使って、隔離したインスタンスに復元します。

ユーザー、視聴履歴、コレクション、手動での照合結果、アートワーク、トリックプレイを有効にした項目が1つ、期待どおりに復元されることを確認します。その後、メディアファイルとサイドカーだけを使った2回目の復旧をテストし、アプリケーションデータベースなしでは何が失われるのかを確認します。

閲覧が快適に応答し、アプリストレージの増加が予測可能で、意図したとおりメディアを可能な限り読み取り専用に保て、文書化したバックアップによって再構築不可能な部分をすべて復元できるなら、そのレイアウトは適切です。速度、容量、移植性に関する実際の問題が復元テストで明らかになった場合にのみ、保存場所を変更してください。