Plexのバックアップ、復元、拡張をまとめて計画する方法

最初の容量変更前に、アプリケーションの状態、メディア、バックアップ、復元先、拡張のトリガーを分離して、Plexの復旧と拡張を一体として設計しましょう。

バックアップは、約束したサービスを再現できて初めて役に立ちます。また、拡張は、その後も復旧経路が機能して初めて安全だと言えます。何を復元する必要があるのか、どの程度のデータ損失まで許容できるのか、家庭内でどれくらい待てるのかを定義しましょう。そのうえで、Plexの状態、メディア、認証情報、バックアップコピー、復旧用スペース、将来のストレージにそれぞれ明確な役割を持たせ、移行やアップグレードのたびにテストできるようにします。

ストレージ構成の前に復旧の約束を定義する

起動ドライブの故障、データベースの削除、メディアディスクの損傷、サーバーの紛失が発生した後、家庭内で何を期待するのかを書き出しましょう。答えはデータの種類によって異なる場合があります。メディアファイルが残っていても、Plexの設定、ユーザー、視聴状態、カスタムポスター、自動化設定を再構築するのは大変です。個人の録画は代替がきかない一方で、市販のメディアは別の入手元から復元できるかもしれません。

復元可能な各コピーについて、許容できる経過時間と、重要なサービスを復旧するまでの最大時間を設定します。これは抽象的な略語ではなく、運用上の約束です。視聴状態は1日分失っても許容できるが、家族の動画は1本も失えないのであれば、両者に同じバックアップ頻度や保存先を割り当てるべきではありません。メディア全体の復元に週末まで待てるなら、すべてのコンポーネントを即時復旧向けに設計する必要はありません。

初期ストレージ構成が成立するのは、それぞれの約束に担当、コピー、復元操作、復元先がある場合だけです。バックアップファイルの名前だけがあり、一時的な復旧先がない計画は不完全です。プライマリアレイが利用できることを前提にした計画では、そのアレイ自体の故障には対応できません。

Plexの状態をメディア容量から分離する

Plexのデータベース、メタデータ、設定、サービス構成を、明確に識別できる永続的な場所に保管します。メディアは専用の容量階層に保存します。トランスコードファイルなど再構築可能なキャッシュは、使い捨てのワークスペースに置きます。認証情報、暗号鍵、バックアップ設定はメディアツリーの外に保管し、大容量ファイルのコピーを完全なサーバー復旧と取り違えないようにします。

この分離により、最初の復旧手順を短縮できます。小さく一貫性のあるアプリケーション状態のコピーを隔離したサービスに復元し、代表的なメディアの一部を接続して、数テラバイトの転送を開始する前にインストールが起動することを確認できます。また、メディアボリューム全体が、データベース、権限、コンテナのマウントを復元できるかどうかを隠してしまうのも防げます。

データの役割ごとに、所有者、識別子、マウントポイント、パスの前提条件を記録します。別のメディアパスを指す復元済みデータベースは、無傷でも利用できない場合があります。サービスIDが異なるコピー済みコンテナフォルダーは起動しても、ライブラリを読み取れないことがあります。復旧を左右するのは、ファイルの存在だけでなく、トポロジーと権限です。

障害ごとに異なる復旧経路を用意する

サービスにはプライマリシステムを使い、迅速なローカル復旧には別のバックアップ先を用意し、失うことが許容できないデータには、別の障害ドメインを用意します。3つ目の場所には、オフサイトストレージ、暗号化されたクラウド容量、別の場所に保管して順番に入れ替えるメディアなどを利用できます。重要なのは独立性です。停電、アカウント侵害、誤削除、ストレージコントローラーの故障が、同じ経路を通じてすべてのコピーに及ばないようにします。

頻繁に変更される小容量のPlex状態には世代保持を適用し、問題のあるアップデートやデータベース障害によって最後に使えたコピーが上書きされないようにします。代替のきかないメディアは、失った場合に必要となるコピー数で保護します。再ダウンロード可能なメディアは、復元時間と入手元の可用性が許容範囲であれば、より低コストのポリシーにできます。プライマリ筐体内の冗長性は可用性の層であり、これらの独立した復旧経路の1つではありません。

バックアップの完了状況を確認できるようにします。最後に成功したアプリケーション状態のコピー、メディア保護の状況、保存先の容量、検証結果を記録します。正常終了したジョブでも、復号、マウント、または想定したパスへの再マッピングができないなら、復旧の約束を満たしたことにはなりません。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

拡張でパスを変更する前に復元をリハーサルする

Plexの状態を、隔離したコンテナ、仮想マシン、予備ホスト、または本番ライブラリに書き込めない一時ディレクトリに復元します。可能な限り、本番と同じサービスIDとパス構成を使います。少量のメディアサンプルを接続し、データベースが開くこと、ライブラリが表示されること、権限が機能すること、再生が開始できること、重要な設定や履歴が存在することを確認します。

空の復元先からリハーサルを行い、認証情報の取得、正しいバックアップの特定、ファイルの復元、所有権の修正、サービスの検証までの時間を計測します。復旧では、実際のストレージ転送速度よりも、パスの決定や不足しているメモのために待たされることが多いため、推定転送速度より実測値のほうが役に立ちます。

ソフトウェアのバージョン、バックアップ日、復元先、実施内容、例外、最終確認を短い復旧記録に残します。コンテナイメージ、OS、ストレージマウント、サービスID、暗号化方式、バックアップツールを変更した後は、テストを繰り返します。以前の記録が現在のシステムを正確に説明できなくなった時点で、拡張によって復旧経路の一部はすでに無効になっています。

拡張のたびにバックアップ予算を更新する

新しいディスクシェルフ、大容量プール、別のNAS、追加のコンピュートノードは、容量だけのアップグレードではなく、トポロジーの変更として扱います。保護すべきデータ量、バックアップウィンドウに必要な時間、保存先に必要な空き容量、同等の復元をどこで実行できるかを再計算します。本番データを移動する前に、マウントパス、権限、監視、インベントリを更新します。

新しい経路が検証に合格するまで、以前の復旧経路を利用できる状態にして、変更を段階的に進めます。データをコピーまたはレプリケートし、件数と代表的なファイルを検証し、1つのパスを切り替えた後、古い場所を廃止する前にPlexとバックアップの確認を行います。ストレージ、サービスID、アプリケーションバージョン、バックアップ方式を同じメンテナンス時間内に一度に変更するのは避けましょう。変数が多すぎると、復元に失敗した原因の特定が難しくなります。

バックアップ先が新しい保護対象セットを収容できない場合、復元先に十分な空き容量がなくなった場合、または実測の復旧時間が家庭内の約束を超えた場合、拡張は停止します。新しいストレージが唯一の本番コピーになる前に、保護容量を増やすか、復旧の約束を絞り込みます。

復旧の証拠を使って役割分離の時期を判断する

サーバーの交換やアプリケーションのメンテナンスが、ライブラリのサイズや接続に左右されて遅れているなら、コンピュートとメディアストレージを分離します。プライマリシステムだけでは本番コピーと復旧コピーを同じ障害にさらさず保持できなくなったら、専用のバックアップ先を追加します。実測したバックアップや復元の時間が、いずれかのストレージではなく経路によって制限されているなら、ネットワーク容量を増やします。

空き容量の予測、バックアップ時間、復元リハーサルの所要時間、ピーク時の再生テストを拡張のトリガーとして使います。新しいコンポーネントは、測定された制限のいずれかを改善し、他の制限を維持しなければなりません。2つ目のストレージ名前空間、文書化されていない認証情報、新しいマウント依存関係を追加しただけで復旧の約束を改善しないなら、レジリエンスではなく複雑性を増やしたことになります。

復旧を担当する人がシステムのリハーサルを実施できない場合、すべてのコピーが同じ管理者アカウントに依存している場合、または拡張したライブラリの保護に必要な時間と容量が家庭内で許容できる範囲を超えた場合は、そこで止めます。再び拡張する前に、保持期間を短くする、代替可能なメディアとして再分類する、トポロジーを簡素化するといった対応を行います。

最終的なセットアップルール

Plexの拡張は、新しいトポロジーに対してバックアップ容量、復元先、権限、パス、実測復旧時間を更新し、検証して初めて完了します。