

# REL 9 データはどのようにバックアップするのですか?
<a name="w2aac19b9c11b5"></a>

目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件を満たすように、データ、アプリケーション、設定をバックアップします。

**Topics**
+ [REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 バックアップを保護し、暗号化する](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 データバックアップを自動的に実行する](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する](rel_backing_up_data_periodic_recovery_testing_data.md)

# REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する
<a name="rel_backing_up_data_identified_backups_data"></a>

 すべての AWS データストアは、バックアップ機能を備えています。Amazon RDS や Amazon DynamoDB などのサービスは、ポイントインタイムリカバリ (PITR) を有効にする自動バックアップを追加でサポートします。これにより、現在時刻の 5 分前までの任意の時刻にバックアップを復元することができます。多くの AWS サービスは、バックアップを別の AWS リージョン にコピーする機能を備えています。AWS Backup は、複数の AWS のサービスにまたがってデータ保護を一元化し、自動化できるツールです。 

 Amazon S3 をセルフマネージドおよび AWS マネージドデータソースのバックアップ先として使用できます。Amazon EBS、Amazon RDS、Amazon DynamoDB などの AWS サービスには、バックアップを作成する機能が組み込まれています。サードパーティー製のバックアップソフトウェアも使用できます。 

 オンプレミスのデータを AWS クラウド にバックアップするには、 [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) または [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)を使用します。Amazon S3 バケットは、このデータを AWS に保存するために使用できます。Amazon S3 は、 [Amazon Glacier または S3 Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) など複数のストレージ階層を提供して、データストレージのコストを削減します。 

 他のソースからデータを再生成することによって、データリカバリのニーズを満たすこともできます。例えば、 [Amazon ElastiCache レプリカノード](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) または [RDS リードレプリカ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) を使用して、プライマリが失われた場合にデータを再生成できます。このようなソースを使用して、 [目標復旧時点 (RPO) と目標復旧時間 (RTO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)を満たすことができる場合、バックアップは不要です。別の例として、Amazon EMR を操作している場合、 [S3 から EMR にデータを再生成できる限り、HDFS データストアをバックアップする必要はありません](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/). 

 バックアップ戦略を選択するときには、データの復旧にかかる時間を考慮してください。データの復旧に必要な時間は、バックアップのタイプ (バックアップ戦略の場合) やデータ再生成メカニズムの複雑性に依存します。この時間は、ワークロードの RTO 以内でなければなりません。 

 **期待される成果:** 

 データソースが識別され、重要性に基づいて分類されている。次に、RPO に基づいてデータ復旧戦略を確立します。この戦略には、これらのデータソースをバックアップするか、他のソースからデータを再生成する能力を持つことが含まれます。データ損失の場合、実装された戦略によって、定義された RPO および RTO 内でのデータの復旧または再生成が可能になります。 

 **クラウド成熟度フェーズ:** Fondational 

 **一般的なアンチパターン:** 
+  ワークロードのすべてのデータソースとそれらの重要性を認識していない。 
+  重要なデータソースのバックアップを取っていない。 
+  重要性を評価基準として使用せずに、一部のデータソースのみのバックアップを取る。 
+  RPO が定義されていないか、バックアップの頻度が RPO を満たしていない。 
+  バックアップが必要かどうか、またはデータを他のソースから再生成できるかどうかを評価していない。 

 **このベストプラクティスを確立するメリット:** バックアップが必要な場所を特定し、バックアップを作成するメカニズムを実装するか、外部ソースからデータを再生成できるようにすることで、停止時にデータを復元し、復旧する能力が高まります。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 ワークロードが使用する AWS のサービスとリソースのバックアップ機能を理解し、使用します。ほとんどの AWS のサービスは、ワークロードデータをバックアップする機能を提供します。 

 **実装手順:** 

1.  **ワークロードのすべてのデータソースを特定します**.データは、データベース、 [からの脱却](https://aws.amazon.com/products/databases/)io1 [ボリューム](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)io1 [ファイルシステム](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)io1 [ロギングシステム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)、および [オブジェクトストレージなど、多くのリソースに保存できます](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html).ウェブアプリケーションのバックエンドに関する推奨事項については、 **リソース** セクションで、 **関連するドキュメント** から、データが保存されるさまざまな AWS のサービスと、これらのサービスが提供するバックアップ機能に関するものを参照してください。 

1.  **重要性に基づいてデータソースを分類します**.データセットごとにワークロードにとっての重要度が異なるため、回復力の要件も異なります。例えば、一部のデータは重要であり、ゼロに近い RPO を必要とするかもしれませんが、その他のデータは重要度が低く、より高い RPO や部分的なデータ損失に耐えられるかもしれません。同様に、データセットごとに RTO 要件も異なります。 

1.  **AWS またはサードパーティのサービスを使用して、データのバックアップを作成します**. [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) は、AWS にさまざまなデータソースのバックアップを作成できるマネージドサービスです。また、これらのサービスのほとんどは、バックアップを作成する機能をネイティブで備えています。AWS Marketplace には、これらの機能を提供する多数のソリューションも用意されています。ウェブアプリケーションのバックエンドに関する推奨事項については、 **リソース** 以下に記載されているリソースの中で、さまざまな AWS のサービスからデータのバックアップを作成する方法に関する情報を参照してください。 

1.  **バックアップしないデータについては、データ再生成メカニズムを確立します**.さまざまな理由から、他のソースから再生成できるデータはバックアップしないという選択をすることもあるでしょう。バックアップの保管にコストがかかるため、バックアップを作成するよりも、必要なときにソースからデータを再現したほうが安いという状況もあるかもしれません。別の例としては、バックアップからの復元にかかる時間が、ソースからデータを再生成するよりも長く、結果として RTO に反する場合です。このような状況では、トレードオフを考慮して、データ復旧が必要なときに、これらのソースからデータを再生成する方法について、十分に定義されたプロセスを確立してください。例えば、データの分析を行うために、Amazon S3 からデータウェアハウス (Amazon Redshift など) 、または MapReduce クラスター (Amazon EMR など) にデータをロードしてある場合、これは他のソースから再生成できるデータの例になるかもしれません。これらの分析の結果がどこかに保存されているか再現可能である限り、データウェアハウスまたは MapReduce クラスターで発生した障害でデータが失われることはありません。ソースから再現できる例には他にも、キャッシュ (Amazon ElastiCache など) や RDS リードレプリカなどがあります。 

1.  **データをバックアップするサイクルを確立します**.データソースのバックアップの作成は定期的なプロセスであり、頻度は RPO に依存します。 

 **実装計画の工数レベル:** 中 

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 

[REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する](rel_planning_for_recovery_objective_defined_recovery.md) 

[REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する](rel_planning_for_recovery_disaster_recovery.md) 

 **関連するドキュメント:** 
+  [「AWS Backup とは。」](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [AWS DataSync とは?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html) 
+  [ボリュームゲートウェイとは?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) 
+  [APN パートナー: バックアップを支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Backup) 
+  [AWS Marketplace: バックアップに活用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) 
+  [Amazon EBS スナップショット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html) 
+  [Amazon EFS のバックアップ](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html) 
+  [Amazon FSx for Windows File Server のバックアップ](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html) 
+  [ElastiCache for Redis のバックアップと復元](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html) 
+  [Creating a DB Cluster Snapshot in Neptune (Neptune での DB クラスタースナップショットの作成)](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html) 
+  [DB スナップショットの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html) 
+  [スケジュールに従って実行する EventBridge ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) 
+  [クロスリージョンレプリケーション](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) と Amazon S3 
+  [EFS-to-EFS AWS Backup](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/) 
+  [Amazon S3 へのログデータのエクスポート](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 
+  [オブジェクトのライフサイクル管理](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html) 
+  [On-Demand Backup and Restore for DynamoDB (DynamoDB のオンデマンドバックアップと復元)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html) 
+  [DynamoDB のポイントインタイムリカバリ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html) 
+  [Working with Amazon OpenSearch Service Index Snapshots (Amazon OpenSearch Service インデックススナップショットの操作)](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html) 

 **関連動画:** 
+  [AWS re:Invent 2021 - Backup, disaster recovery, and ransomware protection with AWS (AWS によるバックアップ、ディザスタリカバリ、ランサムウェア保護)](https://www.youtube.com/watch?v=Ru4jxh9qazc) 
+  [AWS Backup Demo: Cross-Account and Cross-Region Backup (デモ: クロスアカウントおよびクロスリージョンバックアップ)](https://www.youtube.com/watch?v=dCy7ixko3tE) 
+  [AWS re:Invent 2019: Deep dive on AWS Backup (AWS Backup の深掘り), ft.Rackspace (STG341)](https://youtu.be/av8DpL0uFjc) 

 **関連する例:** 
+  [Well-Architected ラボ: Amazon S3 の双方向クロスリージョンレプリケーション (CRR) の実装](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/) 
+  [Well-Architected ラボ: データのバックアップと復元のテスト](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 
+  [Well-Architected ラボ: 分析ワークロードのフェイルバックによるバックアップと復元](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/) 
+  [Well-Architected ラボ: ディザスタリカバリ - バックアップと復元](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/) 

# REL09-BP02 バックアップを保護し、暗号化する
<a name="rel_backing_up_data_secured_backups_data"></a>

 AWS IAM などの認証と承認を使用して、バックアップへのアクセスを制御し、検出します。暗号化によりバックアップのデータ保全性が損なわれることを防止、検出します。 

 Amazon S3 は、保管時のデータを暗号化するための方法をいくつかサポートしています。Amazon S3 はサーバー側の暗号化を使用して、オブジェクトを暗号化されていないデータとして受け入れてから、保存時に暗号化します。クライアント側の暗号化を使用すると、ワークロードアプリケーションはデータを Amazon S3 に送信する前に暗号化することに対して責任を負います。どちらの方法でも、AWS Key Management Service (AWS KMS) を使ってデータキーを作成して保存することもできますし、自分でキーを用意し、そのキーに責任を持つこともできます。AWS KMS を使用すると、IAM を使用してポリシーを設定し、データキーと復号化されたデータにアクセスできるユーザーとアクセスできないユーザーにわけることができます。 

 Amazon RDS では、データベースの暗号化を選択すると、バックアップも暗号化されます。DynamoDB のバックアップは常に暗号化されます。 

 **一般的なアンチパターン:** 
+  データに対するのと同一の、バックアップおよび復元オートメーションへのアクセスを設定する。 
+  バックアップを暗号化しない。 

 **このベストプラクティスを確立するメリット:** バックアップを保護することで、データの改ざんを防止し、データの暗号化により、誤って公開されたデータへのアクセスが防止されます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  各データストアで暗号化を使用します。ソースデータが暗号化されている場合、バックアップも暗号化されます。 
  +  RDS での暗号化を有効にします。RDS インスタンスの作成時に、AWS Key Management Service を使用して、保管時の暗号化を設定できます。
    +  [Amazon RDS リソースの暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) 
  +  EBS ボリュームの暗号化を有効にします。デフォルトの暗号化を設定するか、ボリュームの作成時に一意のキーを指定できます。
    +  [Amazon EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) 
  +  必要な Amazon DynamoDB 暗号化を使用します。DynamoDB は保管中のすべてのデータを暗号化します。AWS 所有の AWS KMS キーを使用するか、AWS マネージド KMS キーを使用して、アカウントに保存されるキーを指定できます。
    +  [保管時の DynamoDB 暗号化](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) 
    +  [暗号化されたテーブルの管理](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html) 
  +  Amazon EFS に保存されているデータを暗号化します。ファイルシステムを作成するときに暗号化を設定します。
    +  [EFS でのデータとメタデータの暗号化](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) 
  +  送信元と送信先のリージョンで暗号化を設定します。KMS に保存されているキーを使用して Amazon S3 で保管時の暗号化を設定できますが、キーはリージョン固有です。レプリケーションを設定するときに、送信先キーを指定できます。
    +  [CRR 追加設定: AWS KMS に保存された暗号化キーを使用したサーバー側の暗号化 (SSE) で作成されたオブジェクトをレプリケートする](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html) 
+  バックアップにアクセスするための最小特権のアクセス許可を実装します。セキュリティのベストプラクティスに従って、バックアップ、スナップショット、およびレプリカへのアクセスを制限します。 
  +  [セキュリティの柱: AWS Well-Architected](./wat.pillar.security.en.html) 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Marketplace: バックアップに活用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) 
+  [Amazon EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) 
+  [Amazon S3: 暗号化を使用しデータを保護する](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html) 
+  [CRR 追加設定: AWS KMS に保存された暗号化キーを使用したサーバー側の暗号化 (SSE) で作成されたオブジェクトをレプリケートする](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html) 
+  [保管時の DynamoDB 暗号化](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html) 
+  [Amazon RDS リソースの暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html) 
+  [EFS でのデータとメタデータの暗号化](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) 
+  [AWS でのバックアップの暗号化](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html) 
+  [暗号化されたテーブルの管理](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html) 
+  [セキュリティの柱: AWS Well-Architected](./wat.pillar.security.en.html) 

 **関連する例:** 
+  [Well-Architected ラボ: Amazon S3 の双方向クロスリージョンレプリケーション (CRR) の実装](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/) 

# REL09-BP03 データバックアップを自動的に実行する
<a name="rel_backing_up_data_automated_backups_data"></a>

目標復旧時点 (RPO) によって、またはデータセット内の変更によって通知される定期的なスケジュールに基づいて、バックアップが自動的に行われるように設定します。データ損失の少ない重要なデータセットは頻繁に自動バックアップする必要がありますが、多少の損失は許容できる重要度の低いデータは、バックアップの頻度を少なくすることができます。

 AWS Backup を使用して、さまざまな AWS データソースの自動化されたデータバックアップを作成できます。Amazon RDS インスタンスは 5 分ごとにほぼ連続的にバックアップでき、Amazon S3 オブジェクトは 15 分ごとにほぼ連続的にバックアップできます。これにより、バックアップ履歴内の特定の時点へのポイントインタイムリカバリ (PITR) が可能になります。Amazon EBS ボリューム、Amazon DynamoDB テーブル、Amazon FSx ファイルシステムなど、その他の AWS データソースについては、AWS Backup は 1 時間ごとの頻度で自動バックアップを実行できます。これらのサービスでは、バックアップ機能もネイティブに提供されています。ポイントインタイムリカバリを備えた自動バックアップを提供する AWS サービスとしては、 [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html)io1 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html)、および  [Amazon Keyspaces (Apache Cassandra 向け)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html) があります。これらはバックアップ履歴内の特定の時点への復元が可能です。その他の AWS データストレージサービスのほとんどが、1 時間ごとの定期バックアップをスケジュールする機能を提供しています。 

 Amazon RDS と Amazon DynamoDB は、ポイントインタイムリカバリを使用した継続的なバックアップを提供しています。Amazon S3 バージョニングは、一度有効にすると、自動で実行されます。[Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) を使用して、Amazon EBS スナップショットの作成、コピー、および削除を自動化できます。また、Amazon EBS-backed Amazon マシンイメージ (AMI) とその基盤となる Amazon EBS スナップショットの作成、コピー、廃止、および登録解除も自動化できます。

 バックアップの自動化と履歴を一元的に確認できるようにするために、AWS Backup は完全マネージド型の、ポリシーベースのバックアップソリューションを提供します。AWS Storage Gateway を使用して、クラウド内およびオンプレミスの複数の AWS のサービスにわたってデータのバックアップを一元化および自動化します。 

 バージョン管理に加えて、Amazon S3 はレプリケーション機能も備えています。S3 バケット全体を同じまたは異なる AWS リージョン にある別のバケットに自動的にレプリケートできます。 

 **期待される成果:** 

 一定の周期でデータソースのバックアップを作成する自動化されたプロセス。 

 **一般的なアンチパターン:** 
+  バックアップを手動で実行する。 
+  バックアップ機能があるが、自動化にバックアップが含まれていないリソースを使用する。 

 **このベストプラクティスを確立するメリット:** バックアップを自動化することで、バックアップが RPO に基づいて定期的に作成され、作成されない場合はアラートが送信されます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>

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

1.  **ワークロードの RPO を** 決定します。AWS に ANF サーバーを構築するための詳細については、 [REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する](rel_planning_for_recovery_objective_defined_recovery.md) これに関するガイダンスを参照してください。 

1.  **自動バックアップソリューションまたはマネージドサービスを使用します**。AWS Backup はフルマネージドサービスであり、 [AWS のサービス、クラウド、およびオンプレミスでのデータ保護の一元化と自動化を容易にします](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups).バックアッププランは AWS Backup の機能であり、バックアップするリソースと、これらのバックアップを作成する頻度を定義するルールの作成を可能にします。この頻度は、ステップ 2 で確立した RPO によって通知される必要があります。 [この WA ラボは、](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) AWS Backup を使用して自動バックアップを作成する方法に関するハンズオンガイダンスを提供します。データを保存するほとんどの AWS サービスでは、バックアップ機能がネイティブで提供されています。例えば、RDS は、ポイントインタイムリカバリ (PITR) 付きの自動バックアップに利用できます。 

1.  **オンプレミスデータソースやメッセージキューなど、自動バックアップソリューションまたはマネージドサービスによってサポートされないデータソースについては、** 信頼できるサードパーティソリューションを使用して自動バックアップを作成することを検討してください。または、AWS CLI または SDK を使用してこれを行うオートメーションを作成することができます。AWS Lambda 関数または AWS Step Functions を使用して、データバックアップの作成にかかわるロジックを定義し、Amazon EventBridge を使用して RPO (ステップ 2 で確立) に基づく頻度で実行することができます。 

 **実装計画の工数レベル:** 低 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [APN パートナー: バックアップを支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Backup) 
+  [AWS Marketplace: バックアップに活用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) 
+  [スケジュールに従って実行する EventBridge ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) 
+  [「AWS Backup とは。」](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [「AWS Step Functions とは何ですか?」](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) 

 **関連動画:** 
+  [AWS re:Invent 2019: Deep dive on AWS Backup (AWS Backup の深掘り), ft.Rackspace (STG341)](https://youtu.be/av8DpL0uFjc) 

 **関連する例:** 
+  [Well-Architected ラボ: データのバックアップと復元のテスト](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 

# REL09-BP04 データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する
<a name="rel_backing_up_data_periodic_recovery_testing_data"></a>

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

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

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

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

 **一般的なアンチパターン:** 
+  バックアップを復元しますが、復元が使用可能であることを確認するためのデータのクエリや取得は行いません。 
+  バックアップが存在することを前提とする。 
+  システムのバックアップが完全に動作可能であり、そこからデータを復旧できることを前提とする。 
+  バックアップからデータを復元または復旧する時間がワークロードの RTO の範囲内であることを前提とする。 
+  バックアップに含まれるデータがワークロードの RPO の範囲内であることを前提とする。 
+  ランブックを使用せずに、または確立された自動手順の外部で、アドホックに復元する。 

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

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

## 実装のガイダンス
<a name="implementation-guidance"></a>

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

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

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

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

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

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

1.  **本番環境で現在使われている確立されたデータ復元プロセスを使用して、** テスト復元を行います。これらのプロセスは、オリジナルデータソースのバックアップ方法、バックアップそのもののフォーマットとストレージ場所、またはデータが他のソースから再生成されるかどうかによって異なります。例えば、 [AWS Backup などのマネージドサービスを使用している場合、バックアップを新しいリソースに容易に復元できます](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html).AWS Elastic Disaster Recovery を使用した場合、 [リカバリドリルを開始できます](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html). 

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

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

1.  **データ検証に失敗した場合や、** 復元と復旧に必要な時間がワークロードについて確立された RTO を超えている場合は、関係者に通知します。これを行うオートメーションを実装するときには、 [このラボのように、](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)Amazon Simple Notification Service (Amazon SNS) などのサービスを使用して、メールや SMS などで関係者にプッシュ通知を送信できます。 [これらのメッセージは、Amazon Chime、Slack、Microsoft Teams などのメッセージングアプリケーションに発行したり、](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) または [AWS Systems Manager OpsCenter を使用して OpsItems としてタスクを作成するために使用したりすることもできます](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html). 

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

![\[自動化されたバックアップおよび復元プロセスを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/automated-backup-restore-process.png)


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

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Backup でデータ復旧検証を自動化する](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/) 
+  [APN パートナー: バックアップを支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Backup) 
+  [AWS Marketplace: バックアップに活用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup) 
+  [スケジュールに従ってトリガーする EventBridge ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html) 
+  [DynamoDB のオンデマンドバックアップと復元](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html) 
+  [「AWS Backup とは。」](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [「AWS Step Functions とは何ですか?」](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) 
+  [AWS Elastic Disaster Recovery とは](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) 
+  [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 

 **関連する例:** 
+  [Well-Architected ラボ: データのバックアップと復元のテスト](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 