Plexアプリのデータ、キャッシュ、バックアップを分離する方法

信頼性の高いPlexのストレージ構成では、ストレージ階層を割り当てる前に、アプリデータ、再構築可能なキャッシュ、一時作業領域、バックアップコピーを分離します。

コンテナやホストを置き換えてもデータベースとメタデータを保持しつつ、復旧を脅かすことなくキャッシュやトランスコードデータを消去できる設計にしてください。バックアップは、稼働中の状態データとは異なる障害経路に保存します。これらの役割を明確にすれば、不要な大量コピーで消費されるのではなく、レイテンシに敏感な状態データ用にSSD容量を確保できます。

サーバーの状態データを永続性のある低レイテンシの経路に保つ

Plexのデータベース、メタデータ、設定、アイデンティティに紐づく状態データがサーバーを定義するため、実行環境を置き換えても保持されるべきです。この用途では、生の容量よりも予測可能なレイテンシと復旧可能性が重視されます。

アクセスパターンがI/Oに敏感な場合、データベースのワークロードはストレージのレイテンシと帯域幅に大きく左右されます。そのため、測定結果が裏付ける場合は、アクティブなアプリケーションの状態データを高速な階層に配置することが有効です。

Plexの状態データはコンテナイメージとは独立してマウントし、所有権、バックアップ、復元の手順を文書化してください。永続アプリデータのレイアウトは、ストレージ設計の安定した中核です。

キャッシュとトランスコードデータを再構築可能なものとして分類する

キャッシュによって応答性が向上し、トランスコード用領域には高速な一時書き込みが必要になる場合がありますが、どちらもライブラリの正本として扱うべきではありません。これらを失っても、パフォーマンスが低下するだけで、サーバーのアイデンティティが失われることがあってはなりません。

キャッシュされたページはストレージからの読み取りを繰り返さずに済み、再構築も可能です。そのため、キャッシュは Plex のデータベースやメタデータの状態とは異なる耐久性クラスに属します。

一時データは安全に消去できるパスに置き、特定の復旧要件がない限り、コストのかかる長期バックアップの対象から除外してください。

バックアップは異なる障害経路上に置く

稼働中の Plex の状態と同じ場所に保存したバックアップは、一部のアプリケーション上のミスからは保護できますが、デバイスの喪失、ストレージプールの破損、ホストの故障からは保護できません。復旧用コピーは障害の影響範囲をまたいで保管してください。

バックアップシステムには、独自の容量とデータ変動の特性があるため、アプリデータ用デバイスの未使用領域ではなく、独立したストレージの役割としてバックアップ先の容量を確保してください。

稼働中の状態を保存するデバイスとは別の場所に、少なくとも1つコピーを保管し、復元にかかる時間を定めてください。スナップショットは役に立ちますが、唯一の復旧手段ではありません。

Featured

ZimaBoard 2 - 大きなアイデアを実現するミニホームサーバー

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

置き換えテストでレイアウトを検証する

優れた役割マップがあれば、インシデント発生時にパスを分類し直すことなく、ランタイムを置き換え、状態を再接続し、キャッシュを再生成して、バックアップから復元できます。

記録された状態とバックアップの保存場所だけを使い、使い捨てのホストで Plex を再構築してから、キャッシュのパスを意図的に空にしてください。サーバーの識別情報やライブラリが失われる場合は、役割が正しく分離されていません。

ストレージを今後アップグレードする際は、復元に成功した構成をトポロジーの基準にしてください。