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

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

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

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

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

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

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

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

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

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

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

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

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

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

このベストプラクティスを活用しない場合のリスクレベル: ミディアム

実装のガイダンス

バックアップおよび復元機能をテストすることで、停止時にこれらのアクションを実行できるという安心感が得られます。定期的にバックアップを新しい場所に復元して、テストを実行し、データの完全性を確認します。実行すべき一般的なテストは、

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

  1. 現在、手動でバックアップされている データソースと、これらのバックアップの保存場所を特定します。AWS に ANF サーバーを構築するための詳細については、 REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する この実装方法に関するガイダンスを参照してください。

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

  3. データの重要度に基づいて、データ復元の RTO と RPO を確立します。AWS に ANF サーバーを構築するための詳細については、 REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する この実装方法に関するガイダンスを参照してください。

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

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

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

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

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

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

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

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

実装計画の工数レベル: 検証基準の複雑性に応じて、中～高。

リソース

関連するドキュメント:

関連する例: