View a markdown version of this page

REL09-BP04 データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する - AWS Well-Architected Framework

REL09-BP04 データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する

復旧テストを実行して、バックアッププロセスの実装が目標復旧時間 (RTO) と目標復旧時点 (RPO) を満たしていることを検証します。

期待される成果: バックアップからのデータを、十分に定義されたメカニズムを使用して定期的に復旧することで、ワークロードについて確立された目標復旧時間 (RTO) 内での復旧が可能であることを確認できます。バックアップからの復元により、オリジナルデータを含むリソースになり、破損したりアクセス不能になっていたりするデータがなく、目標復旧時点 (RPO) 内のデータ損失であることを確認します。

一般的なアンチパターン:

  • バックアップを復元しますが、復元が使用可能であることを確認するためのデータのクエリや取得は行いません。

  • バックアップが存在することを前提とする。

  • システムのバックアップが完全に動作可能であり、そこからデータを復旧できることを前提とする。

  • バックアップからデータを復元または復旧する時間がワークロードの RTO の範囲内であることを前提とする。

  • バックアップに含まれるデータがワークロードの RPO の範囲内であることを前提とする。

  • ランブックを使用せずに、または確立された自動手順の外部で、必要に応じて復元する。

このベストプラクティスを活用するメリット: バックアップの復旧をテストすると、データの紛失や破損を心配せずに、必要なときにデータを復元できること、ワークロードの RTO 内で復元と復旧が可能であること、ならびにデータ損失がワークロードの RPO の範囲内であることを確認できます。

このベストプラクティスを確立しない場合のリスクレベル:

実装のガイダンス

バックアップおよび復元機能をテストすることで、停止時にこれらのアクションを実行できるという安心感が得られます。定期的にバックアップを新しい場所に復元して、テストを実行し、データの完全性を確認します。実行する必要がある一般的なテストには、すべてのデータが利用可能かどうか、破損していないかどうか、アクセス可能かどうか、データ損失がワークロードの RPO 内に収まるかどうかを確認することなどがあります。そのようなテストは、復旧メカニズムが十分に高速であり、ワークロードの RTO に対応できることを確認するのにも役立ちます。

AWS を使用して、テスト環境を立ち上げ、そこにバックアップを復元して RTO および RPO が機能するかを評価し、データコンテンツと完全性のテストを実行できます。

さらに、Amazon RDS および Amazon DynamoDB はポイントインタイムリカバリ (PITR) を許可します。継続的バックアップを使用すると、データセットを指定された日時の状態に復元できます。

すべてのデータが使用可能であり、破損しておらず、アクセス可能であり、データ損失がワークロードの RPO の範囲内であることを確認します。そのようなテストは、復旧メカニズムが十分に高速であり、ワークロードの RTO に対応できることを確認するのにも役立ちます。

AWS Elastic Disaster Recovery は、Amazon EBS ボリュームの継続的なポイントインタイムリカバリのスナップショットを提供します。ソースサーバーがレプリケートされると、設定済みのポリシーに基づいて、ポイントインタイムの状態が経時的に記録されます。Elastic Disaster Recovery を使用すると、トラフィックをリダイレクトせずにテストおよびドリル目的でインスタンスを起動することにより、これらのスナップショットの整合性を検証できます。

実装手順

  1. 現在バックアップされているデータソースを特定し、バックアップが保存されている場所を確認します。実装のガイダンスについては、以下を参照してください REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する.

  2. 各データソースのデータ検証に使用する基準を確立します。データのタイプが異なると、プロパティも異なり、異なる検証メカニズムが必要になることがあります。本番環境での使用を決定する前に、このデータを検証する方法を考慮してください。データを検証するための一般的な方法としては、データタイプ、フォーマット、チェックサム、サイズ、またはこれらの組み合わせなど、データとバックアッププロパティをカスタム検証ロジックで使用することです。例えば、復元されたリソースと、バックアップが作成された時点でのデータソースの間でチェックサム値を比較します。

  3. データの重要度に基づいて、データ復元の RTO と RPO を確立します。実装のガイダンスについては、以下を参照してください REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する.

  4. データ復旧機能を評価します。バックアップおよび復元戦略をレビューして、RTO および RPO を満たせるかどうかを理解し、必要に応じて戦略を調整します。AWS Resilience Hub を使用して、ワークロードの評価を実行できます。アセスメントは、回復力ポリシーに対してアプリケーション設定を評価し、RTO および RPO 目標を満たすことができるかどうかを報告します。

  5. 本番環境で現在確立されているデータ復元プロセスを使用してテスト復元を行います。これらのプロセスは、オリジナルデータソースのバックアップ方法、バックアップそのもののフォーマットとストレージ場所、またはデータが他のソースから再生成されるかどうかによって異なります。例えばこれは、AWS Backup などのマネージドービスを使用している場合は、新しいリソースでバックアップを復元するという簡単な作業となります。AWS Elastic Disaster Recovery を使用した場合、リカバリドリルを開始できます。

  6. 前のステップで確立したデータ検証の基準に基づいて、復元したリソースからのデータ回復を検証します。復元され、復旧されたデータには、バックアップ時点で最新のレコードまたはアイテムが含まれていますか? このデータはワークロードの RPO の範囲内ですか?

  7. 復元と復旧に必要とした時間を測定して、決定済みの RTO と比較します。このプロセスは、ワークロードの RTO の範囲内ですか? 例えば、復元プロセスが開始されたときのタイムスタンプと復旧検証が完了したときのタイムスタンプを比較して、このプロセスの所要時間を計算します。すべての AWS API コールにはタイムスタンプが付けられており、この情報は、AWS CloudTrail で提供されています。この情報から復元プロセスが開始したときの詳細がわかりますが、検証が完了したときの終了タイムスタンプが検証ロジックによって記録される必要があります。自動化されたプロセスを使用している場合は、この情報の保存に Amazon DynamoDB などのサービスを使用できます。さらに、多くの AWS のサービスは、特定のアクションが発生したときのタイムスタンプ付きの情報を提供するイベント履歴を備えています。AWS Backup では、バックアップと復元アクションは、ジョブと呼ばれており、これらのジョブにはメタデータの一部としてタイムスタンプ情報が含まれ、復元と復旧の所要時間の測定に使用できます。

  8. データの検証に失敗した場合や、復元と復旧に必要な時間がワークロードについて確立された RTO を超えている場合は、ステークホルダーに通知します。このラボのように、このプロセスのオートメーションを実装する場合、Amazon Simple Notification Service (Amazon SNS) などのサービスを使用して、E メールや SMS などのプッシュ通知をステークホルダーに送信できます。これらのメッセージは、Amazon Chime、Slack、Microsoft Teams などのメッセージングアプリケーションに発行したりAWS Systems Manager OpsCenter を使用して、OpsItems としてタスクを作成するために使用したりすることができます。

  9. このプロセスを定期的に実行するように自動化します。例えば、AWS Lambda や AWS Step Functions の状態マシンなどのサービスを使用して、復元および復旧プロセスを自動化でき、Amazon EventBridge を使用して、下のアーキテクチャ図に示されているように、このオートメーションワークフローを定期的にトリガーすることができます。Automate data recovery validation with AWS Backup (AWS Backup を使用して復元データの検証を自動化する) 方法を確認してください。さらに、この Well-Architected ラボでは、いくつかのステップのオートメーション方法の 1 つについてのハンズオンエクスペリエンスを提供しています。

自動化されたバックアップおよび復元プロセスを示す図

図 9.自動化されたバックアップおよび復元プロセス

実装計画に必要な工数レベル: 中~高 (検証基準の複雑性に依存)。

リソース

関連するドキュメント:

関連する例: