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

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 を使用して、下のアーキテクチャ図に示されているように、このオートメーションワークフローを定期的にト呼び出すことができます。AWS Backup でデータリカバリの検証を自動化する方法を学びます。この Well-Architected ラボでは、いくつかのステップを自動化するための方法を解説します。

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

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

実装計画に必要な工数レベル: 検証基準の複雑さに応じて中から高

リソース

関連ドキュメント:

関連する例: