每日 EBS 支持的 EC2 快照应保留多长时间？我们正在使用EC2 自动备份备份（每日）两个与 Web 应用程序相关的 EBS 卷（操作系统和数据）。如果我理解正确的话，如果发生故障，我们可以从最新的快照创建新的实例。
但是，我相信这些快照是增量的，尽管每个快照（在 AWS 控制台中）的大小与创建它们的 EBS 卷的大小相同，但我认为它们只是记录更改，对吗？
但这绝对是我对快照的理解不足的地方，因为我不明白如果我们删除旧快照，我们怎么能确保保留所有需要的数据，因此我不知道我们应该保留这些数据多长时间。
更新 过了一会儿我发现这，这似乎意味着我可以毫无顾忌地删除除最新帖子之外的所有帖子。如果情况确实如此，并且觉得这对其他人有用，我可以自己回答，或者如果太明显，可以关闭此帖子。
答案1
我可以毫无顾忌地删除除最新内容之外的所有内容
假设您不需要在拍摄最新快照时卷上已删除或覆盖的任何数据，这是正确的。
EBS 快照是逻辑上增量——不是身体上增量。下面巧妙地解释了这种差异：
从技术上讲，EBS 卷的快照并不包含数据……它们包含指向备份数据块的指针列表，EBS 会代表您将这些数据块存储在 S3 中（并向您收取存储费用）。对于每个新快照，如果在卷上遇到与前一个快照没有变化的块，并且这些块已经以相同的内容存储在 S3 中，则不会再次存储它们 — — 新快照仅引用另一个快照作业已经存储的块……这就是为什么您可能没有高昂的存储费用。
这就是我所说的“逻辑上”增量。新更改的块（自上次快照以来）保留在 S3 中，但它们实际上并不“在”最新快照中 - 它们被最新快照以及任何未来创建的快照引用，直到它们发生变化。
EBS 快照完全与文件系统无关。它们不知道如何块被使用，只是它们在快照之间发生了变化。快照是块级（而非文件级）操作，因此，无论块的粒度如何，¹ 如果只更改了大文件的一部分，则在原地（不移动磁盘上的文件）只会重新备份文件更改的部分。（一个简单的例子是不断增长的日志文件）。
当您删除快照时，这些快照引用的数据块将从 S3 存储中清除（停止对这些数据块的存储计费）当且仅当没有其他快照引用它们。否则，它们当然会被保留，因为它们仍然需要。
如果您删除除最新快照之外的所有快照，则存储在 S3 中且不需要恢复该单个快照的所有块都将被清除，因此您的可计费快照存储大小将完全等于卷的大小，因为只有这些块会保留在 S3 存储中。（从技术上讲，它应该更小，因为 EBS 显然在快照上使用可逆压缩算法，但细节不公开，但原则上，一个只有一个快照的 8GB 卷引用了正好 8GB 的快照块）。
这就是为什么快照大小总是在控制台和 API 中显示卷大小，而不是某种“增量”大小的原因——快照不“包含”任何数据，但它包含指向恰好足够的备份数据块的指针，以便用与快照作业启动时卷上存在的内容相同的内容填充卷。这就是你的“不受惩罚”的来源。
清除所有旧快照，将清除一些备份块，并将节省你一些这取决于快照之间的卷变化程度。如果变化很小，则清除它们可以释放的备份块存储量非常小，而且它们不会花费您太多钱。
由于文件被删除、覆盖等风险，在问题出现前的几天可能会被注意到...保留一天以上的数据似乎是明智的，但这种理由与 EBS 快照的工作方式无关。
我的策略是通过内部自动化实施的，即每天保留一个每日快照，持续几天，然后将其缩减为每周保留一个快照，持续几周，最后永久保留每个卷的每月快照，或更短时间，具体取决于保留策略。（我的自动化在卷上使用“魔术”标签来自定义每个卷级别的保留和时间，但大多数卷都使用该默认策略。）
顺便说一句，谈到 S3，可能需要澄清的是，在这种设置中，EBS 是 S3 的“客户”，而不是您——这就是为什么您无法在 S3 中看到这些备份数据。
¹“无论块的粒度如何”– 我指的是从 EBS 的角度来看“备份块”的大小。据我所知，这个大小没有记录，但我的假设是，在这种情况下，“块”几乎肯定大于设备向操作系统呈现的“块大小”，因为一位数 KiB 的备份块大小会导致一个尴尬的大块数字要处理、跟踪、存储和重新加载的块。