検索結果:

AWS Backup スナップショット

AWSスナップショット

  • 整合性を保つためにアプリケーション認識型バックアップを使用：データベースやERPシステムなどの重要なアプリケーションには、アプリケーション認識型バックアップのメカニズムを統合します。これにより、アプリケーション層での整合性が確保され、実行中のインスタンスのスナップショットによる破損を回避できます。
  • ワークロードの重要度に基づくバックアップのライフサイクルポリシーを実装：例えば、重要なワークロードには、より頻繁なスナップショットとより長い保持期間が必要となる場合がありますが、重要でないワークロードは保持期間を短く設定できます。
  • 最小限のベースイメージでAMIを最適化：AMIを作成する際には、不要なデータや一時ファイルを除外してベーススナップショットのサイズを縮小します。スナップショットが小さくなればストレージの消費量が減り、コストを削減し、復元時間を短縮できます。
  • 災害復旧シナリオのためのテスト環境を作成： 定期的にスナップショットをテスト専用環境にリストアしてテストします。これにより、バックアップの整合性が検証されます。
  • AWS Cost Explorerでスナップショットの使用状況を監視： AWS Cost Explorerを使用して、スナップショットに関連するコストの傾向を特定します。これにより、使用されていないバックアップや冗長なバックアップが明らかになり、コスト最適化のためにクリーンアップや保持ポリシーの調整を促すことができます。

スナップショットのアーカイブにAmazon S3を使用のヒント

AWSコスト

●アーカイブ前にデータの分類を優先：すべてのスナップショットが同じように重要であるわけではありません。 コンプライアンスやDRなどの重要なスナップショットと、より長い検索時間を許容できるスナップショットを区別するために、堅牢なデータ分類ポリシーを導入します。

●アーカイブからの取得に関するSLAをDR計画に統合：GlacierまたはDeep Archiveにスナップショットをアーカイブした場合、取得に数分から数時間かかる場合があります。 災害復旧（DR）計画では、こうした取得SLAを考慮して、予期せぬ遅延を回避する必要があります。

●S3 Object Lockを使用して保持の徹底を自動化：S3 Object Lockを使用して重要なスナップショットの不変性を徹底し、早期の削除を防止して、規制へのコンプライアンスを確保します。 また、誤ってまたは悪意を持って削除されることも防ぎます。

●重要アーカイブスナップショットには、クロスリージョンレプリケーションを活用：スナップショットをアーカイブする前に、クロスリージョンレプリケーション（CRR）を有効にします。これにより、リージョンがダウンした場合でも、アーカイブされたデータは別のリージョンで利用可能になります。

●AWS Cost Explorer を使用して定期的にコスト監査を実施する：S3 GlacierとDeep Archiveはコスト削減をもたらしますが、これらは長期間にわたって気づかぬうちに蓄積される可能性があります。AWS Cost Explorerを使用して定期的にアーカイブコストを監査し、スナップショットのライフサイクルポリシーが最適化されていることを確認してください。

スナップショット＆イメージレベルバックアップ

AWSスナップショット

サーバ仮想化の基本要素である、1台のホスト上に存在するすべてのVMは、物理サーバのリソースを共有し、1つのハイパーバイザによって管理されていることを忘れてはいけません。もし、これら全てのVMが同時にバックアップジョブを開始したらどうなるのでしょうか？ハイパーバイザーやホストサーバのリソースに負担がかかり、遅延が発生したり、最悪の場合バックアップが失敗したりする可能性があります。

 

ここでスナップショットの威力が発揮されます。スナップショットはVMのある時点のコピーを取得し、フルバックアップと比較してはるかに迅速な処理が可能です。スナップショット自体はバックアップではありませんが、イメージベースバックアップの重要な構成要素です。VMスナップショットがバックアップと同等でない主な理由は、VMから独立して保存できないからです。このため、スナップショットの取得頻度によっては、VMのストレージ容量が急速に増大し、パフォーマンスに影響を与える可能性があります。このため、取得するスナップショットの数量を認識することが重要です。

AWSスナップショットの限界

AWSスナップショット

単一のAWSアカウントと比較的少数のリソースを持つユーザーにとって、バックアップの自動化と一貫したポリシーの適用は簡単なプロセスです。しかし、複数の地域に多数のAWSアカウントを持つユーザーにとって、バックアップを監視しながらすべてのアカウントで一貫したデータ保護を実施することは、非常に困難でコストがかかる可能性があります。Kubernetesのようなアプリケーションでは、ITチームはより洗練されたデータ保護メカニズムを必要とし、スナップショットだけに頼っていては復旧目標を達成できないかもしれないので、問題はさらに複雑になります。

 

さらに、すべてのバックアップが異なる地域の異なるアカウントにコピーされることを保証する問題もあります。地域間で何千ものバックアップを移行するのは非常に高価であり、一般的なエグレス・チャージよりは低いものの、AWSは地域間のデータコピーに課金することになります。最後に、AWSのスナップショットはストレージ効率が良いが、長期間保存するとかなりコストがかかる可能性があります。

AWSスナップショットと3-2-1バックアップルール

AWSスナップショット

効果的なバックアップとリカバリのシステムは、バックアップの古典的な3-2-1ルールに従っています – データのコピーを少なくとも3つ、少なくとも2つの異なるタイプのメディアに保存し、そのうち1つはオフサイトに保存します。

 

2つの異なるストレージシステムにデータを保存することは、プライマリシステムがダウンした場合にコピーが破損しないようにするためのリスク管理戦術です。このため、常に別のバックアップシステムを持ち、プライマリとバックアップの両方に同じストレージを使用しないようにします。スナップショットを作成した時点で、データのコピーを別のシステムに保存していることになるので、このルールの一部はAWSスナップショットを使用して簡単に遵守することができます。

 

少なくとも1つのバックアップコピーをオフサイトに保存することが、厄介な部分です。AWSスナップショットを別のリージョンにコピーすることは可能ですが、自動化するのは難しく、コストもかかります。あるリージョンから別のリージョンにデータをコピーすると、イグレスチャージが発生し、コストのかかる不要なコピーが作成されます。また、この概念をすべてのAWSアカウントに一貫して適用し、一元的な管理とレポーティングを維持することは困難です。

初めに：AWSスナップショットとは何ですか？

AWSスナップショット

AWSスナップショットとは、EC2インスタンスやEBSボリュームなどのリソースのイメージコピーで、AWSアカウント内のオブジェクトストレージに保存される。フルまたはベースラインスナップショットは、保護されたリソースの単一時点からの同一コピーである。最初のスナップショットが作成されると、それ以降の増分スナップショットには、最後のスナップショットが取得された後に変更されたすべてのブロックが含まれるようになります。

 

AWSスナップショットは完全なコピーであるため、破損または削除されたリソースを復元するために使用することができ、一般的にプライマリコピーが破損した場合、ITが最初に検索するものです。例えば、EC2インスタンスやEBSボリュームが破損しても、スナップショットには影響しないので、チームは簡単に復旧することができます。

 

これは、AWSスナップショットがバックアップのための理想的なデータソースであることを意味します 。 それは、異なるシステムに格納されているデータの独立したコピーを提供します。そらは、AWSで損傷したリソースを回復するための最も簡単で迅速な方法であり、シンプルでスピーディな災害復旧のための素晴らしいリソースを示しています。

 

<<続き>>

https://www.climb.co.jp/faq/faq-category/aws-snapshot

 

クライムAWSソリューション群