Plexの状態とは何か、どの部分を永続化する必要があるのか？

エヴァ・ウォン

IceWhale author

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

What Is Plex State, and Which Parts Must Persist? - Zima Store Online

Plexの状態とは、プロセス、コンテナ、ホストを置き換えた後も同じライブラリ体験を復元するために保持しておく必要があるサーバー情報です。

この状態はプログラムのバイナリより広い一方、Plexが触れるすべてのバイトよりは狭い範囲を指します。ライブラリデータベース、メタデータ、設定、サーバーの識別情報、構成は永続的な復旧単位に含まれます。一方、元のメディアには独自のストレージライフサイクルがあり、トランスコード用の一時領域は一時的なものです。これらの役割を分けることで、再起動、バックアップ、移行、再構築を整理して考えやすくなります。

Plexの状態とは、プロセス終了後も残る情報です

重要な情報がプロセスのメモリ外に保存されているため、実行中のPlexプロセスを停止・起動しても、サーバーの利用体験は失われません。コンテナでも同じ原則が当てはまり、イメージや書き込み可能なコンテナレイヤーを交換できる一方で、アプリケーションデータは永続化できます。

コンテナストレージは、永続データをコンテナより長く保持する必要がある理由を示しています。したがって、Plexの状態は、アプリケーション層を再作成した際に破棄されない、定義済みのホストパスまたはボリュームに保存する必要があります。

対象範囲は機能面で定義できます。ある情報を失うことで、復元後のサーバーが別のインストールのように見えたり、再スキャンが必要になったり、ユーザーにとって重要な選択が消えたりするなら、それは状態または復旧対象の定義に含めるべきです。

データベースとメタデータがライブラリ体験を維持します

ライブラリデータベースには、メディアのファイル名だけから正確に再作成できない関係や状態が記録されています。メタデータ、アートワーク、マッチング結果、コレクション、視聴履歴、その他サーバーが管理する情報があることで、復元したインストールは同じファイルを新たにスキャンしただけの状態ではなく、以前と同じライブラリとして利用できます。

データディレクトリとサーバー設定は、復旧対象に含めるべきです。目的は実行ファイルだけを復元することではなく、サーバーの利用体験を復元することだからです。プラットフォームによって正確な保存場所は異なるため、バックアップは実際のインストールで使用されているデータパスに紐づける必要があります。

生成されたメタデータは理論上再作成できますが、再構築には時間がかかり、すべてのマッチング結果やユーザーの選択を再現できるとは限りません。再現可能であることと、不要であることは別の概念として扱いましょう。技術的には再生成できるデータでも、復旧の速度や継続性のために永続化する価値がある場合があります。

設定と識別情報がサーバーの動作を維持します

設定は、サーバー名、構成、環境との連携方法を決定します。識別情報や認証関連の情報により、復旧後もクライアントは新しいインストールではなく、想定されていたサーバーとして認識できます。

サーバーのデータディレクトリには、プラットフォームごとに異なる保存場所があります。ただし、この場所は状態を特定するための出発点であり、データベースが変更されている最中にファイルを無条件でコピーしてよいという意味ではありません。

また、ディレクトリ周辺のデプロイ情報も保持してください。サービスアカウント、コンテナのマッピング、環境設定、ポート、マウント、必要なデバイスアクセスなどです。これらはPlexのデータフォルダー外に存在する場合がありますが、復元した状態を利用可能にするために必要です。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

メディアファイルとトランスコード用一時領域は異なるデータの役割を持ちます

元のメディアは再生に不可欠ですが、Plexのアプリケーション状態と同じものではありません。Plexの状態のバックアップによってライブラリや設定を復元しつつ、メディアはNASや別のストレージシステムに置いたままにできます。また、メディアのバックアップでファイルを保護できても、長年にわたるサーバー上の選択や設定までは保持できません。

メディアファイルは、アプリケーションデータの復旧プロセスとは別に保護する必要があります。この分離により、小規模な状態バックアップを数テラバイト規模のメディアアーカイブと混同せずに済みます。

トランスコード用一時領域、一時ダウンロード、多くのキャッシュオブジェクトは、3つ目の役割に該当します。通常は破棄可能な作業データであり、保持することで復旧の目的が変わることを特定のワークフローが示さない限り、永続的な復旧対象には含めないでください。

永続化とは、再起動・再構築・移行後も状態が残ることです

永続性を確認するには、3段階のテストが役立ちます。まず、プロセスまたはコンテナを再起動し、同じサーバーが戻ることを確認します。次に、同じ状態を参照する形でアプリケーション層を再作成します。最後に、クリーンなターゲットへコピーを復元し、想定した識別情報、ライブラリ、設定、パスが利用できることを確認します。

ホームサーバーの復旧では、単純なメディアの再スキャンだけではきれいに再現できない部分であるため、設定とメタデータの復元に重点が置かれることがよくあります。コミュニティの手順はシナリオとして役立ちますが、実際に保持すべき状態の範囲は、対象プラットフォーム上で確認してください。

状態の取得方法を選ぶ際には、稼働中と停止後のバックアップの境界によって、永続性と整合性を区別できます。データが永続ストレージに保存されていても、信頼できる復旧ポイントにするには、安全なスナップショットや短時間の停止が必要になる場合があります。