Plexの設定・キャッシュ・ユーザーデータ：実際に永続化が必要なのはどれ？

サーバーとライブラリを定義するPlexの状態を永続化し、復旧設計上必要でない限り、一時キャッシュやトランスコードデータは再構築可能なものとして扱います。

重要なのはフォルダーの容量ではなく、復旧可能性です。設定、データベース、メタデータ、アートワーク、視聴状態への参照、サーバーIDは、一貫性を保ちながら再作成するのが難しい、または手間がかかります。一方、一時的なトランスコードファイルや多くのキャッシュデータは再生成できます。保存先を決める前に、各パスを削除した場合に何が起きるかで分類してください。

サーバーの状態は設定ファイルだけではない

Plexのデプロイメントは、Webインターフェースに表示される設定だけでなく、複数の永続ファイルによって定義されます。ライブラリデータベースとメタデータディレクトリには、復元したインスタンスを以前と同じ状態に見せるための関連情報やサーバー状態が保存されています。

Plexのメタデータ保存領域には、データベース、アートワーク、インデックス、その他のサーバー状態ファイルが含まれます。

マウントされているPlexのパスをすべて一覧化し、新しいホスト上で同じライブラリとメタデータを再現するために必要なものに印を付けます。パスにサーバーのデータベースやメタデータの状態が含まれている場合は、永続バックアップセットに含めてください。交換可能なランタイムの外部にコンテナデータを永続化することで、再構築可能なレイヤーと、コンテナの交換後も保持すべき状態を分離できます。

キャッシュは重要だが、通常は再構築できる

キャッシュは、ライブラリの正本ではなく、レイテンシーを低減するためのものです。キャッシュが温まった状態を失うと、しばらくサーバーの動作が遅く感じられることがありますが、データベースの喪失と同じように扱うべきではありません。

Linuxのページキャッシュは、データがメモリ上で温まると、ストレージへの繰り返しアクセスを減らせます。

既知の破棄可能なキャッシュだけを削除してテストインスタンスを再起動し、完全な状態のサーバーとウォームアップ時の挙動を比較してください。サーバーのライブラリIDや設定が失われる場合、削除したパスは単なる破棄可能なキャッシュではありません。

データベースの整合性によってバックアップの優先度が変わる

取得したデータベースが内部的に整合していなければ、永続データは役に立ちません。書き込み中にコピーしたデータベースは、制御された停止状態で作成したバックアップよりも信頼性が低くなる可能性があります。

SQLiteの書き込み安全性では、制御された書き込みが推奨されるため、稼働中のPlexデータベースを権限の確認に使用すべきではありません。

可能な場合は、書き込み処理を一時停止または停止するバックアップ時間帯を設定し、コピーしたデータベースを開けることを確認してください。ファイルのコピー自体は成功しているのに復元テストに失敗する場合は、保持期間を延ばす前にバックアップの整合性を改善します。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

一時的なトランスコード領域は別の復旧クラスに分類する

トランスコード出力は再生処理のために作成される作業データであり、権威あるライブラリデータではありません。速度や容量を優先して配置できますが、Plexデータベースと同じ耐久性ポリシーを適用する必要はありません。

Plexのトランスコードが必要な場合、クライアントとの互換性に応じて、デコードやエンコードの処理がサーバー側に移されます。

デプロイメントファイルでは、トランスコード用マウントとキャッシュ用マウントを、永続的なPlexデータ用マウントとは分けて記載してください。一時パスが固有の設定やデータベースファイルの唯一の保存場所になっている場合は、次回の移行前に分類を見直します。