AWS EC2スナップショット-どのくらいの期間保持する必要がありますか？
EBSでバックアップされた毎日のEC2スナップショットをどのくらいの期間保持する必要がありますか？ ec2-automate-backup を使用して、Webアプリケーションに関連する2つのEBSボリューム（OSとデータ）を（毎日）バックアップしています。私が理解していれば、失敗した場合は、最新のスナップショットから新しいインスタンスを作成できます。
ただし、これらのスナップショットはインクリメンタルであり、作成元のEBSボリュームと同じサイズで（AWSコンソールに）リストされていても、変更を記録しているだけだと思います。 ？
古いスナップショットを削除した場合に必要なすべてのデータを確実に保持できる方法がわからないため、スナップショットについての私の理解は間違いなくここにあります。 。
[〜＃〜] update [〜＃〜]しばらくして見つけた this 、これは文字通り削除できることを示唆しているようです最新のものを除き、すべて免責されます。それが事実であり、これが他の人に役立つと思われる場合、私はこれに自分で答えることができます。または、それがあまりにも明白である場合は、これを閉じてください。
私は文字通り最新のものを除いてすべてを削除することができます
最新のスナップショットを作成したときに、ボリューム上ですでに削除または上書きされたデータが必要ない場合、それは事実です。
EBSスナップショットは論理的にインクリメンタルです物理的にインクリメンタルではありません。違いを説明する賢さは次のとおりです。
EBSボリュームのスナップショットには、技術的にはデータが含まれていません...バックアップされたデータブロックへのポインターのリストが含まれています。これは、EBSがユーザーに代わってS3に保存します（および保存料金を請求します）。新しいスナップショットごとに、前のスナップショットから変更されていないため、同じコンテンツでS3にすでに保存されているブロックがボリュームで検出された場合、それらは再度保存されません。新しいスナップショットは、別のスナップショットによって既に保存されているブロックを参照するだけです。スナップショットジョブ...これが、異様なストレージ料金を請求していない理由です。
これは、私が「論理的に」インクリメンタルと言う意味です。新しく（最後のスナップショット以降に）変更されたブロックはS3に保持されますが、実際には最新のスナップショットに「含まれている」わけではありません。それらは、変更されるまで、そのスナップショットと、作成された将来のスナップショットによって参照されます。
EBSスナップショットは、ファイルシステムに完全に依存しません。 howブロックが使用されていることについては、スナップショット間で変更されたことだけがわかりません。スナップショットはブロックレベル（ファイルレベルではなく）の操作であるため、ブロックの細分性が何であれ、¹大きなファイルの一部のみが（ディスク上でファイルを移動せずに）変更された場合、変更されたもののみファイルの一部は新しくバックアップされます。 （単純な例は、継続的に増大するログファイルです）。
スナップショットを削除すると、それらのスナップショットによって参照されているブロックがS3ストレージから削除されます（これらのブロックのストレージに対する課金が停止されます）if and only if他のスナップショットがそれらを参照していません。それ以外の場合は、もちろん、それらはまだ必要なので、保存されます。
最新のスナップショットを除くすべてを削除すると、S3に保存されている、その1つのスナップショットを復元する必要のないすべてのブロックが削除されるため、請求可能なスナップショットのストレージサイズは、ボリュームのサイズとまったく同じになります。これらのブロックはS3ストレージに残ります。 （技術的には、EBSはスナップショットに可逆圧縮アルゴリズムを使用しているようですが、詳細は公開されていませんが、原則として、1つのスナップショットを含む8 GBのボリュームは、8 GBのスナップショットブロックを正確に参照するため、小さくする必要があります）。
これが、スナップショットサイズが、ある種の「増分」サイズではなく、常にコンソールとAPIのボリュームサイズを表示する理由です。スナップショットにはデータが「含まれていません」が、埋めるのに十分なバックアップデータブロックへのポインタが含まれています。スナップショットジョブの開始時にボリュームに存在していたものと同じ内容のボリューム。そして、これがあなたの「不処罰」の出番です。
これらの古いスナップショットをすべて削除すると、バックアップブロックのsomeが削除され、スナップショット間で変更されるボリュームの量に応じて、someのコストが節約されます。変更がほとんどない場合、それらをパージすることによって解放されるバックアップブロックストレージは非常に少なくなり、それほどコストはかかりません。
ファイルが削除されたり上書きされたりするリスクがあるため、問題が発生するまでに数日かかる場合があります... 1日以上保持するのが賢明なようですが、その理由はEBSスナップショットの動作とは関係ありません。
社内の自動化によって実装された私のポリシーは、毎日のスナップショットを数日間保持し、それらを数週間の毎週のスナップショットの保持に切り詰め、最後に各ボリュームの毎月のスナップショットを永久に保持するか、保持に応じてそれ以下にすることです。ポリシー。 （私の自動化は、ボリュームで「マジック」タグを使用して、ボリュームごとのレベルで保持とタイミングをカスタマイズしますが、そのデフォルトのポリシーはほとんどのボリュームで使用されます。）
ちなみに、S3の話では、EBSがこのセットアップではS3の「顧客」であり、あなたではないことを明確にする必要があります。そのため、S3でこのバックアップデータを表示することはできません。
¹「ブロックの粒度が何であれ」 –これは、EBSの観点から見た「バックアップブロック」のサイズを意味します。このサイズは、私が知る限り、文書化されていませんが、このコンテキストでの「ブロック」は、オペレーティングシステムに提示されるデバイスの「ブロックサイズ」よりもほぼ確実に大きいと想定しています。 1桁のKiBは、ジャグリング、追跡、保存、およびリロードするブロックの数が非常に大きくなりますnumber。