AWS EC2 快照 - 它们应该保留多长时间?

tob*_*obi 5 snapshot amazon-ec2 amazon-ebs amazon-web-services

EBS 支持的每日 EC2 快照应保留多长时间?我们正在使用ec2-automate-backup备份(每日)两个 EBS 卷 - 操作系统和数据 - 与 Web 应用程序有关。如果我理解,如果发生故障,我们可以从最近的快照创建新实例。

但是,我相信这些快照是增量的,即使每个快照(在 AWS 控制台中)都与创建它们的 EBS 卷的大小相同,我认为它们只是记录更改,是吗?

这绝对是我对快照的理解下降的地方,因为我不明白如果我们删除旧快照我们可以确保保留所有需要的数据,因此我不知道我们应该坚持多久.

更新 片刻之后我发现了这个,这似乎表明我可以从字面上删除除最新的之外的所有内容而不受惩罚。如果是这种情况并且认为这对其他人有用,我可以自己回答这个问题,或者如果太明显了,请随意关闭它。

Mic*_*bot 15

我可以毫无顾忌地删除除最近的以外的所有内容

假设您不需要在拍摄最新快照时已在卷上删除或覆盖的任何数据,这是真的。

EBS 快照在逻辑上是增量的——而不是物理增量。这是解释差异的聪明之处:

EBS 卷的快照在技术上不包含数据……它们包含指向备份数据块的指针列表,EBS 代表您将这些数据块存储在 S3 中(并为您收取存储费用)。对于每个新快照,如果卷上遇到的块与之前的快照没有变化,因此已经以相同的内容存储在 S3 中,它们不会再次存储——新快照只是引用另一个已经存储的块快照工作......这就是为什么您可能没有古怪的存储费用。

这就是我所说的“逻辑上”增量的意思。新的(自上次快照以来)更改的块保留在 S3 中,但它们并不是真正“在”最新快照中——它们被它引用,并且被任何未来制作的快照引用,直到它们发生更改。

EBS 快照完全与文件系统无关。他们不知道块是如何使用的,只知道它们在快照之间发生了变化。快照是块级(不是文件级)操作,因此,无论块的粒度是多少,¹ 如果只更改了大文件的一部分,就地(不移动磁盘上的文件)那么只有更改的文件的一部分将是新备份的。(一个简单的例子是一个不断增长的日志文件)。

当您删除快照时,当且仅当没有其他快照引用它们时,这些快照引用的块将从 S3 存储中清除(停止对这些块的存储计费)。否则,当然,它们会被保留下来,因为它们仍然是需要的。

如果您删除除最新快照以外的所有快照,则 S3 中存储的所有不需要恢复单个快照的块都将被清除,因此您的计费快照存储大小将完全等于卷的大小,因为只有这些块将保留在 S3 存储中。(从技术上讲,它应该更小,因为 EBS 显然对快照使用了可逆压缩算法,但细节不公开,但原则上,一个 8GB 卷与恰好一个快照,正好引用 8GB 的​​快照块)。

这就是为什么快照大小总是在控制台和 API 中显示卷大小,而不是某种“增量”大小——快照不“包含”任何数据,但它包含指向完全足够的备份数据块的指针来填充内容与快照作业开始时存在于卷上的内容相同的卷。这就是你的“有罪不罚”的由来。

清除所有这些旧快照,将清除一些备份块,并为您节省一些钱,具体取决于快照之间的卷变化量。如果它变化很小,您将只有很少的备份块存储可以通过清除它们来释放,并且它们不会花费您太多。

由于存在文件被删除、覆盖等的风险,因此可能会在问题出现之前的某个时间段内被发现……保留一天以上似乎是明智的,但这种推理与 EBS 快照的工作方式无关。

我的策略是通过内部自动化实施,每天保留一个每日快照数天,将它们修剪为每周快照保留数周,最后为每个卷永久保留每月快照,或者更少,具体取决于保留时间政策。(我的自动化在卷上使用“魔术”标签来自定义每个卷级别的保留和计时,但该默认策略用于大多数卷。)

顺便说一下,在谈到 S3 时,可能需要澄清一下,在此设置中,EBS 是 S3 的“客户”,而不是您——这就是您无法在 S3 中看到此备份数据的原因。


¹ “无论块的粒度是多少” ——我的意思是从 EBS 的角度来看“备份块”的大小。据我所知,这个大小没有记录,但我的假设是,这个上下文中的“块”几乎肯定大于呈现给操作系统的设备的“块大小”,因为备份块大小为一位数的 KiB 会导致需要处理、跟踪、存储和重新加载的块数量庞大。