NAS バックアップが実際に機能するかどうかをテストする方法
NAS のセットアップ後は、ストレージ プールに冗長性があり、スナップショットが有効になっているか、別の NAS がファイルのコピーを受信しているため、データは保護されていると簡単に想定できます。これらの機能は特定の障害から保護できますが、必要なときにバックアップを復元できることを証明するものではありません。
NAS バックアップの有効性は、必要なデータを適切な期間内に使用可能な状態で復元できるかどうかによって決まります。この記事では、回復プロセスをテストし、何が復元されたかを確認し、必要なときにその手順が引き続き使用できることを確認する方法について説明します。
実際の回復をテストすることから始めます
小さいながらも代表的なファイル セットを復元する
バックアップをテストする最も簡単な方法は、バックアップからデータを復元することです。単一のテキスト ドキュメントを復元するのではなく、複数の種類のファイルが含まれるディレクトリを選択します。写真、ドキュメント、より大きなファイル、およびネストされたディレクトリ構造を持つものを含めます。 NAS からアプリケーションを実行する場合は、そのワークロードを表すファイルまたはデータセットも含めます。選択したデータを別のディレクトリまたは別のマシンに復元します。
バックアップを元のファイルに復元しないでください。テストのポイントは、本番データを危険にさらすことなく、バックアップによって使用可能なコピーを作成できることを証明することです。
復元が完了したら、復元されたファイルを開きます。 JPEG は正しく表示され、PDF は開き、ビデオはファイルの少なくとも一部で再生されるはずです。データベースのバックアップの場合は、バックアップ ファイルが単に存在するかどうかを確認するのではなく、データベース独自の回復プロセスを使用します。
これにより、バックアップ システムによくある問題が明らかになります。それは、不完全なデータ、アクセスできないデータ、または別の場所に保存されたメタデータに依存するデータが生成されても、ジョブが正常に完了する可能性があるということです。同じ原則が NAS スナップショットとレプリケーションにも当てはまります。管理インターフェイスに表示されるスナップショットは、そこから必要なファイルに実際にアクセスできる場合にのみ役立ちます。バックアップ システムが独自のアーカイブを使用している場合は、実際のリカバリ中に使用するのと同じアプリケーションを通じてテスト リストアを実行します。
バックアップがソースと一致することを確認します
復元が成功すると、回復パスが機能していることがわかります。次の問題は、復元されたデータが完全であるかどうかです。
ファイルベースのバックアップの場合は、復元されたディレクトリを元のディレクトリと比較します。などのツールを使用できます rsync 予行演習モードで、どちらの側も変更せずに違いを特定します。
rsync -aHn --delete /path/to/original/ /path/to/restored/
正確なオプションは、ファイルシステムと保存する必要がある属性によって異なります。データにシンボリック リンク、ハード リンク、拡張属性、ACL、またはスパース ファイルが含まれている場合は、比較でそれらが考慮されていることを確認してください。
ZFS ベースの NAS の場合、チェックサムは別の有用な検証層を提供します。 ZFS チェックサムはファイルシステムに保存されているデータを保護しますが、独立したバックアップに同じ論理データセットが含まれていることを自動的に証明するわけではありません。 ZFS データセットをレプリケートする場合は、ZFS 対応レプリケーションを使用し、宛先データセットが存在し、アクセスできることを定期的に確認してください。
メタデータについては見落とされやすいため、ここで触れておきます。バックアップには正しいドキュメントが含まれている可能性がありますが、所有権、権限、ACL、タイムスタンプ、またはアプリケーション固有のメタデータは失われます。それが重要かどうかは、NAS が何を保存するかによって決まります。メディア ライブラリはファイル名とタイムスタンプを考慮する場合がありますが、サーバー構成ディレクトリは正確なアクセス許可と所有権に依存する可能性があります。
アプリケーションによってアクティブに使用されるファイルもテストする必要があります。 NAS に仮想マシン イメージ、コンテナ ボリューム、データベース、または構成リポジトリが保存されている場合、それらのファイルを変更中にコピーすると、使用できない復旧ポイントが作成される可能性があります。アプリケーションのファイルをコピーすれば十分であると考えるのではなく、アプリケーションでサポートされているバックアップ メカニズムをテストしてください。データ自体が検証されたら、テストは個々のファイルからリカバリ システムとしての NAS に移行する必要があります。
元の NAS を使用しないテストリカバリ
計画している障害をシミュレーションする
通常、元のデータをホストしている NAS に依存せずにテストすると、バックアップの信頼性がさらに高まります。
このテストを実行するために何も破壊する必要はありません。別のコンピューター、予備の NAS、仮想マシン、または一時的な保管場所を選択し、そこにバックアップの重要な部分を復元します。バックアップが別の NAS に保存されている場合は、認証、DNS、暗号化キー、構成を元の NAS に依存せずにそのバックアップにアクセスできることを確認してください。
実際の NAS 障害では、一度に複数のものが失われる可能性があるため、これは重要です。ストレージ プールが使用できなくなったり、NAS オペレーティング システムの再インストールが必要になったり、デバイスの構成ファイルが失われたりする可能性があります。バックアップに障害が発生したマシンの構成データベースが必要な場合、バックアップ プロセスは、実際に懸念している障害に対してテストされていません。
暗号化により別の依存関係が追加されます。バックアップが暗号化されている場合は、回復キーまたはパスワードが NAS から独立して利用できることを確認してください。復旧情報は、停止中にアクセスできる場所に保管してください。完全に無傷の暗号化されたバックアップであっても、誰も復号化できなければ実用的な価値はほとんどありません。
回復テストをルーチンに変える
何が機能したかを文書化し、再度テストする
リカバリ テストは、NAS が変更されてもその結果が有効である場合にのみ役立ちます。新しいバックアップ ソフトウェア、暗号化設定、ストレージ ターゲット、アプリケーション、および保持ポリシーによって、元のテストでは存在しなかった問題が発生する可能性があります。
テストの実行中に回復手順を書き留めておくことをお勧めします。私は通常、バックアップの保存場所、バックアップへのアクセス方法、どの認証情報またはキーが必要か、どのソフトウェアが必要か、データの復元に使用されるコマンドやインターフェイスの手順について書きます。また、6 か月後のインシデント時には明らかではなくなる可能性があるため、その時点では明らかであると思われる詳細も含める必要があります。
少量のデータをテストベッドとして使用する
回復チェック専用の小さなテスト データセットを保持します。これは、関心のあるデータの種類を表し、大量のストレージや帯域幅を消費せずに簡単に復元できる必要があります。復元後、内容を確認し、いくつかのファイルを開きます。
また、時間の経過とともにさまざまな回復シナリオをテストする必要があります。たとえば、システムの一部をチェックするファイル レベルのリストア、容量とパフォーマンスをチェックする大規模なデータセットのリストア テスト、ドキュメント、暗号化キー、バックアップ ストレージ、交換用ハードウェアが十分かどうかをテストする完全な NAS リカバリなどです。
関連情報は以下のリンクからご確認いただけます