本番データを危険にさらさずにPlexの復旧をテストする方法

安全なPlexリカバリーテストでは、コピーした状態から本番サーバーを変更せずにサービスを再構築できることを確認します。

使い捨てホストまたは分離コンテナを使用し、読み取り専用または複製したメディアパスに対してコピーしたアプリデータを復元します。テストでは、本番環境に影響を与えずに、サーバーの識別情報、ライブラリ、メタデータ、権限、再生を確認できる必要があります。クリーンな環境でバックアップを単独利用できるようになるまで、リカバリープランが実証されたとはいえません。

リカバリー範囲を定義する

リカバリーに含まれるのは、Plexが起動するかどうかだけではありません。データベース、メタデータ、環境設定、サーバーの識別情報、マウントパス、権限がすべて一体となって復元されなければ、テストは不完全です。

安全なホスト移行には、サーバー状態とパスの継続性を維持する必要があります。記憶を頼りに再構築してはいけません。

テスト用コピーを作成する前に、どのディレクトリ、識別情報、メディアパスを正式なものとして扱うかを書き出します。復元を成功させるために本番環境を変更せず、代わりにリカバリー手順の文書を修正してください。

分離されたランタイムに復元する

分離された復元環境を使うと、実行中のサーバーからファイルを借りてバックアップを修復したくなる誘惑を排除できます。テスト用インスタンスには独自のネットワーク識別情報とアプリデータのコピーを割り当て、成功がリカバリーセットそのものによるものだと確認できるようにします。

復元テストの価値は、ファイルが存在することを確認するのではなく、使用可能なサービスを再構築して、完成したバックアップを検証できる点にあります。

コピーした状態を使って使い捨てインスタンスを起動し、ポートまたはネットワークを明確に分離します。テストによる書き込みが本番のアプリデータパスに到達しないことを確認してください。

データベースと権限を同時に検証する

コピーしたデータベースは内部的には有効でも、所有者やマウントパスが変わったために機能しない場合があります。そのためリカバリーでは、データの整合性と、サービスが必要とするものと同じ実効的な読み書き権限の両方を確認する必要があります。

コンテナ化された復元では、新しいマウント先でも、数値UIDとGIDのマッピングがホストのファイルシステム所有権と一致している必要があります。

復元したライブラリを開き、小規模なメタデータ書き込みを実行して、権限エラーがないかログを確認します。権限のためにその場しのぎのroot修正が必要なら、その要件を文書化したリカバリー手順に追加してください。整然とした永続アプリデータ構成があれば、使い捨ての復元環境で、コピーした状態、マウント、権限だけで十分であり、本番環境から何も借りる必要がないことを実証できます。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

必要になる前にリカバリー時間を測定する

最後のテストは運用面の確認です。正常な状態に到達するまでどれくらいかかり、どのような手動判断が必要でしょうか。数時間の試行錯誤を経て初めて機能する復元は、まだ予測可能なリカバリープランとはいえません。

信頼性の高いリカバリーは、取り消したい障害より前の時点にある正常な復旧ポイントから開始します。

空のランタイムから検証済みの再生に至るまでのクリーンな復元時間を測定し、その結果をバックアップポリシーとともに記録します。大幅なレイアウト変更後には再度測定し、実測したリカバリー時間を最新の状態に保ってください。