REL09-BP01 バックアップが必要なすべてのデータを特定してバックアップするか、ソースからのデータを再現する - 信頼性の柱
実装のガイダンスリソース

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

REL09-BP01 バックアップが必要なすべてのデータを特定してバックアップするか、ソースからのデータを再現する

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

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

クラウド成熟フェーズ: 基礎

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

  • ワークロードのすべてのデータソースとそれらの重要性を認識していない。

  • 重要なデータソースのバックアップを取っていない。

  • 重要性を評価基準として使用せずに、一部のデータソースのみのバックアップを取る。

  • が定義されていないかRPO、バックアップ頻度が を満たせませんRPO。

  • バックアップが必要かどうか、またはデータを他のソースから再生成できるかどうかを評価していない。

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

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

実装のガイダンス

すべての AWS データストアにはバックアップ機能があります。Amazon RDSや Amazon DynamoDB などのサービスは、リカバリ (PITR) を許可する point-in-time自動バックアップもサポートしています。これにより、現在の時刻の 5 分前までいつでもバックアップを復元できます。多くの AWS サービスでは、バックアップを別の にコピーできます AWS リージョン。 AWS Backup は、 AWS サービス間でデータ保護を一元化して自動化する機能を提供するツールです。 AWS Elastic Disaster Recoveryでは、完全なサーバーワークロードをコピーし、オンプレミス、AZ 間、またはリージョン間で継続的なデータ保護を維持できます。復旧ポイント目標 (RPO) は秒単位で測定されます。

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

オンプレミスデータは、 AWS Storage Gatewayまたは AWS クラウド を使用して にバックアップできますAWS DataSync。Amazon S3 バケットを使用して、このデータを AWSに保存できます。Amazon S3 は、Amazon S3 Glacier や S3 Glacier Deep Archive などの複数のストレージ階層を提供し、データストレージのコストを削減します。

他のソースからデータを再生成することによって、データリカバリのニーズを満たすこともできます。例えば、プライマリが失われた場合、Amazon ElastiCache レプリカノードまたは Amazon RDSリードレプリカを使用してデータを再現できます。このようなソースを使用して復旧ポイント目標 (RPO) と復旧時間目標 (RTO） を満たすことができる場合は、バックアップを必要としない場合があります。もう EMR1 つの例として、Amazon S3 EMRから Amazon にデータを再現できる限り、Amazon Amazon S3を操作する場合、HDFSデータストアをバックアップする必要はありません。

バックアップ戦略を選択するときは、データの復旧にかかる時間を考慮してください。データの復旧に必要な時間は、バックアップの種類 (バックアップ戦略の場合) やデータ再生成メカニズムの複雑さに応じて異なります。この時間は、ワークロードRTOの 内に収まる必要があります。

実装手順

  1. ワークロードのすべてのデータソースを特定する。データは、データベース、ボリューム、ファイルシステム、ログ記録システム、オブジェクトストレージなどの多数のリソースに保管できます。リソースセクションを参照して、データが保存されているさまざまな AWS サービスに関連するドキュメントと、これらのサービスが提供するバックアップ機能を確認してください。

  2. 重要性に基づいてデータソースを分類する。データセットごとにワークロードに対する重要度が異なるため、回復力の要件も異なります。例えば、一部のデータは重要でゼロRPOに近い値を必要とする一方で、他のデータはそれほど重要ではなく、高いデータ損失RPOや一部のデータ損失を許容する可能性があります。同様に、データセットごとにRTO要件も異なる場合があります。

  3. AWS またはサードパーティーのサービスを使用してデータ のバックアップを作成します。 AWS Backupは、 でさまざまなデータソースのバックアップを作成できるマネージドサービス AWSです。 は、 への自動サブ秒データレプリケーションAWS Elastic Disaster Recoveryを処理します AWS リージョン。ほとんどの AWS サービスには、バックアップを作成するネイティブ機能もあります。 AWS Marketplace には、これらの機能を提供する多くのソリューションがあります。以下に記載されている「リソース」を参照して、さまざまな AWS のサービスからデータバックアップを作成する方法に関する情報を確認してください。

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

  5. データをバックアップするサイクルを確立する。データソースのバックアップの作成は定期的なプロセスであり、頻度は によって異なりますRPO。

実装計画に必要な工数レベル: 中

リソース

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

REL13-BP01 ダウンタイムとデータ損失の復旧目標を定義する

REL13-BP02 定義された復旧戦略を使用して復旧目標を達成する

関連ドキュメント:

関連動画:

関連する例: