Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

設定
お問い合わせ
フィードバック
AWS Documentation
今すぐ無料サインアップ »
REL09-BP01 バックアップが必要なすべてのデータを特定し、バックアップする、またはソースからデータを再現する - AWS Well-Architected Framework
実装のガイダンスリソース

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

PDFRSS

すべての 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 または AWS DataSyncを使用します。Amazon S3 バケットは、このデータを AWS に保存するために使用できます。Amazon S3 は、 Amazon S3 Glacier または S3 Glacier Deep Archive など複数のストレージ階層を提供して、データストレージのコストを削減します。

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

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

期待される成果:

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

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

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

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

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

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

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

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

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

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

実装のガイダンス

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

実装手順:

  1. ワークロードのすべてのデータソースを特定します.データは、データベース、 からの脱却io1 ボリュームio1 ファイルシステムio1 ロギングシステム、および オブジェクトストレージなど、多くのリソースに保存できます.ウェブアプリケーションのバックエンドに関する推奨事項については、 リソース セクションで、 関連するドキュメント から、データが保存されるさまざまな AWS のサービスと、これらのサービスが提供するバックアップ機能に関するものを参照してください。

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

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

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

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

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

リソース

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

REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する

REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する

関連するドキュメント:

関連動画:

関連する例:

ヘルプが必要ですか?

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.