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

容量を初めて変更する前に、アプリケーションの状態、メディア、バックアップ、復元先、拡張の判断基準を分けて、Plexの復旧と拡張を一体で設計します。

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

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

起動ドライブの故障、データベースの削除、メディアディスクの破損、サーバーの紛失が起きた後、家庭で何を復旧させたいのかを書き出します。データの種類によって答えは異なる場合があります。メディアファイルが残っていても、Plexの設定、ユーザー、再生状況、カスタムポスター、自動化設定の再構築には手間がかかります。個人の録画はかけがえのないものかもしれませんが、市販メディアは別の方法で入手できる場合があります。

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

各項目について、担当者、コピー、復元手順、復元先が定まって初めて、初期ストレージ構成は要件を満たします。一時的な復旧先がないままバックアップファイルだけを挙げた計画は不完全です。プライマリアレイが引き続き利用できることを前提とした計画では、そのアレイの障害に対応できません。

Plexの状態とメディア容量を分ける

Plexのデータベース、メタデータ、設定、サービス構成は、場所が明確な永続ストレージに保存します。メディアは独立した容量層に保存します。トランスコードファイルなど、再生成可能なキャッシュは使い捨ての作業領域に置きます。認証情報、暗号化キー、バックアップ設定はメディアツリーの外に保管し、大容量ファイルのコピーをサーバー全体の復旧と誤認しないようにします。

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

データの役割と合わせて、所有権、識別子、マウントポイント、想定パスを記録してください。別のメディアパスを参照するデータベースは、データ自体が正常でも使えないことがあります。サービス実行ユーザーが異なるコンテナフォルダーをコピーすると、起動してもライブラリを読み込めないことがあります。復旧にはファイルの存在だけでなく、構成と権限も重要です。

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

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

頻繁に変更される容量の小さいPlexの状態データには世代管理を適用し、不適切なアップデートやデータベースの問題で最後に使えるコピーが置き換わらないようにしてください。かけがえのないメディアは、失われた場合の影響に応じた数のコピーで保護します。再ダウンロードできるメディアは、復元時間と入手元の可用性に問題がなければ、より低コストの方針で保護できます。プライマリ筐体内の冗長化は可用性を高める仕組みであり、独立した復旧経路の1つではありません。

バックアップの完了状況を確認できるようにしてください。アプリケーション状態を最後に正常にコピーした日時、メディアの保護状況、保存先の空き容量、検証結果を記録します。ジョブが正常終了しても、復号、マウント、または所定のパスへの対応付けができなければ、復旧の約束を果たしたことにはなりません。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

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

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

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

ソフトウェアのバージョン、バックアップ日、復元先、実施した操作、例外事項、最終確認を記した簡潔な復旧記録を残してください。コンテナイメージ、オペレーティングシステム、ストレージのマウント設定、サービスの実行ユーザー、暗号化方式、バックアップツールを変更したら、テストを繰り返してください。古い記録が現在のシステムを示していないなら、拡張によって復旧手順の一部がすでに無効になっています。

拡張するたびにバックアップ予算を見直す

新しいディスクシェルフ、大容量のストレージプール、独立したNAS、追加のコンピューティングノードは、単なる容量の拡張ではなく、構成の変更として扱ってください。保護が必要なデータ量、バックアップ所要時間、保存先に必要な空き容量、同等の復元先をどこに確保できるかを再計算しましょう。本番データを移動する前に、マウントパス、権限、監視、資産一覧を更新してください。

新しい方法が検証に合格するまで、従来の復旧経路を使える状態に保ちながら変更を段階的に進めてください。データをコピーまたはレプリケーションし、件数と代表的なファイルを検証してから、パスを1つ切り替え、古い保存先を廃止する前にPlexとバックアップを確認します。ストレージ、サービスのID、アプリケーションのバージョン、バックアップ方法を同じ保守時間内に一度に変更するのは避けましょう。同時に変更する要素が多すぎると、復元に失敗したときの原因究明が難しくなります。

バックアップ先に新たな保護対象データを収容できない、復元先の空き容量が不足している、または実測した復旧時間が家庭で許容できる範囲を超えている場合は、拡張を見送ってください。新しいストレージが唯一の本番データのコピーになる前に、保護容量を増やすか、復旧に関する要件を緩和してください。

役割を分けるタイミングを復旧の証拠に基づいて判断する

ライブラリの容量や接続方法が原因で、サーバーの交換やアプリケーションの保守が遅れているなら、コンピューティングとメディアストレージを分離してください。プライマリシステムで本番データと復旧用コピーを同時に保持できず、単一障害点を共有するようになった場合は、専用のバックアップ先を追加してください。バックアップと復元の時間が、両端のディスクではなく経路の性能で制限されている場合は、ネットワーク容量を増やしてください。

空き容量の予測、バックアップ所要時間、復元リハーサル時間、ピーク時の再生テストを拡張の判断基準にしてください。新しいコンポーネントは、測定済みの制約のいずれかを改善し、ほかの制約を悪化させないものでなければなりません。復旧の見通しを改善せずに、2つ目のストレージ名前空間、文書化されていない認証情報、新たなマウント依存関係を追加するなら、耐障害性ではなく複雑さが増しています。

復旧を担う人が手順をリハーサルできない場合、すべてのコピーが同じ管理者アカウントに依存している場合、または拡張したライブラリの保護に、家庭で許容できる以上の時間や容量が必要な場合は、作業を中止してください。次の拡張に進む前に、保存期間を短縮する、再取得可能なメディアを分類し直す、または構成をシンプルにするなどの対策を取りましょう。

最終セットアップのルール

Plexの拡張は、バックアップ容量、復元先、権限、パス、実測した復旧時間を更新し、新しい構成で検証して初めて完了です。