AWS EC2 快照 - 它們應該保留多長時間？
每日 EBS 支持的 EC2 快照應保留多長時間？我們使用ec2-automate-backup來備份（每天）兩個 EBS 卷 - 作業系統和數據 - 與 Web 應用程序有關。如果我理解的話，如果發生故障，我們可以從最近的快照創建新實例。
但是，我相信這些快照是增量的，即使每個（在 AWS 控制台中）列出的大小與創建它們的 EBS 卷的大小相同，我認為它們只是在記錄更改，對嗎?
這絕對是我對快照的理解下降的地方，因為我不明白如果我們刪除舊的快照，我們如何可以確保保留所有需要的數據，因此我不知道我們應該堅持多久.
更新 片刻之後我發現了這個，這似乎表明我可以從字面上刪除除最新的以外的所有內容而不受懲罰。如果是這種情況，並且覺得這對其他人有用，我可以自己回答這個問題，或者如果它太明顯了，請隨意關閉它。
我可以從字面上刪除除最新的以外的所有內容而不受懲罰
假設您在拍攝最近的快照時不需要任何已在卷上刪除或覆蓋的數據，這是正確的。
EBS 快照是邏輯增量的——不是物理增量的。這是解釋差異的聰明之處：
EBS 卷的快照在技術上不包含數據……它們包含指向備份數據塊的指針列表，EBS 代表您將其儲存在 S3 中（並為您的儲存收費）。對於每個新快照，如果在卷上遇到與先前快照未更改的塊，因此已經以相同的內容儲存在 S3 中，它們不會再次儲存 - 新快照僅引用另一個已儲存的塊快照作業…這就是為什麼您可能沒有奇怪的儲存費用的原因。
這就是我所說的“邏輯上”增量的意思。新的（自上次快照以來）更改的塊保留在 S3 中，但它們並不是真正“在”最新的快照中——它們被它引用，並且被任何未來的快照引用，直到它們發生變化。
EBS 快照完全與文件系統無關。他們不知道這些塊是如何使用的，只知道它們在快照之間發生了變化*。*快照是塊級（不是文件級）操作，因此，無論塊的粒度是多少，¹如果只有大文件的一部分被更改，就位（不移動磁碟上的文件），那麼只有更改的文件的一部分將被新備份。（一個簡單的例子是一個不斷增長的日誌文件）。
當您刪除快照時，當且僅當沒有其他快照引用它們時，這些快照引用的塊將從 S3 儲存中清除（停止為這些塊的儲存計費） 。否則，當然，它們會被保留，因為仍然需要它們。
如果您刪除除最新快照之外的所有快照，則將清除儲存在 S3 中且不需要恢復該單個快照的所有塊，因此您的可計費快照儲存大小將完全等於卷的大小，因為只有這些塊將保留在 S3 儲存中。（從技術上講，它應該更小，因為 EBS 顯然對快照使用了可逆壓縮算法，但細節不公開，但原則上，只有一個快照的 8GB 卷，正好引用 8GB 的快照塊）。
這就是為什麼快照大小總是在控制台和 API 中顯示卷大小，而不是某種“增量”大小——快照不“包含”任何數據，但它包含指向要填充的足夠備份數據塊的指針卷的內容與快照作業開始時卷上的內容相同。這就是你的“有罪不罰”的來源。
清除所有這些舊快照，將清除一些備份塊，並為您節省一些錢，具體取決於快照之間的捲變化量。如果它變化很小，您將只有很少的備份塊儲存可以通過清除它們來釋放，而且它們不會花費您那麼多。
由於文件被刪除、覆蓋等的風險，可能會在幾天前發現問題……保留多於一天似乎是明智的，但這種推理與 EBS 快照的工作方式無關。
我通過內部自動化實施的策略是將每日快照保留幾天，然後將它們縮減為每週快照保留幾週，最後為每個卷永久保留每月快照，或者更少，具體取決於保留時間政策。（我的自動化在卷上使用“魔術”標籤來自定義每個卷級別的保留和時間，但大多數卷都使用預設策略。）
順便說一句，在談到 S3 時，可能需要澄清 EBS 在此設置中是 S3 的“客戶”，而不是您——這就是為什麼您在 S3 中看不到此備份數據的原因。
¹ “無論塊的粒度是多少” ——我指的是從 EBS 的角度來看的“備份塊”的大小。據我所知，這個大小是無證的，但我的假設是，在這種情況下，一個“塊”幾乎肯定比呈現給作業系統的設備的“塊大小”大，因為備份塊大小為個位數的 KiB 會導致笨拙地大量塊來處理、跟踪、儲存和重新載入。