每日EBS支持的EC2快照应保留多久？ 我们使用ec2-automate-backup来备份（日常）两个EBS卷 – 操作系统和数据 – 与Web应用程序有关。 如果我明白，如果发生故障，我们可以从最近的快照创build新的实例。
不过，我认为这些快照是增量式的，尽pipe每个列表（在AWS控制台中）的大小与创buildEBS卷的大小相同，但我认为它们只是logging更改，是吗？ ？
这绝对是我对快照理解的地方，虽然我不明白如果我们删除旧的快照，我们可以确保保留所有需要的数据，因此我不知道应该多久才能挂断。
更新时刻后来，我发现这似乎表明我可以从字面上删除除了最近有罪不罚之外的所有。 如果是这种情况，并认为这可能对其他人有用，我可以自己回答，或者如果太明显，可以随意closures它。
我可以从字面上删除所有，但最近有罪不罚
假设您在创build最近的快照时不需要任何已经被删除或覆盖的数据，那是真的。
EBS快照在逻辑上是增量式的 – 不是物理上的增量式的。 聪明才智解释了这种差异：
EBS卷的快照在技术上并不包含数据…它们包含指向备份数据块的指针列表，EBS将以S3的名义存储在S3中（并logging您的存储空间）。 对于每个新的快照，如果在卷上遇到与前一个快照相同的块，并且因此已经存储在S3中的内容相同，则不会再次存储这些快照 – 新快照只是引用另一个已经存储的块快照工作…这就是为什么你可能没有一个奇怪的存储法案。
这就是我所说的“逻辑”增量。 新的（自从上一个快照以来）更改的块在S3中被保留，但它们并不真正在最新的快照中“进入” – 它们被它引用，并且被任何未来的快照所取代，直到它们改变。
EBS快照完全是文件系统不可知的。 他们不知道如何使用块，只是在快照之间更改。 快照是块级（而不是文件级）操作，因此，无论块的粒度如何，¹如果只有大文件的一部分发生了变化，就地（不移动磁盘上的文件），那么只有更改文件的一部分将被新备份。 （一个简单的例子是一个不断增长的日志文件）。
删除快照时， 当且仅当没有其他快照引用快照时，这些快照所引用的块才会从S3存储中清除（停止存储这些块的计费）。 否则，当然，他们被保留下来，因为他们仍然需要。
如果删除除最近的快照以外的所有快照，则存储在S3中的所有不需要还原该单个快照的块都将被清除，因此您的可计费快照存储大小将与卷的大小完全相同，因为只有这些块将保留在S3存储中。 （从技术上说，它应该更小，因为EBS显然在快照上使用可逆压缩algorithm，但细节不公开，但原则上，具有恰好一个快照的8GB卷正好引用8GB快照块。
这就是为什么快照大小总是显示控制台和API中的卷大小，而不是某种“增量”大小 – 快照不会“包含”任何数据，但它包含指向准确填充的备份数据块的指针内容与快照作业开始时卷上的内容相同的卷。 这就是你的“有罪不罚”的地方。
清除所有这些旧的快照，将清除一些备份块，并将节省您一些钱，具体取决于快照之间的音量变化。 如果它变化很小，那么你将只有很less的备份块存储，通过清除它们就可以释放它们，而且它们不会花费太多的成本。
由于文件被删除，覆盖等风险，在问题可能被注意之前的几天内，保持不止一天似乎是明智的，但是这种推理与EBS快照的工作方式无关。
我的策略是通过内部自动化来实现的，就是每天保持每天快照几天，把它们修剪成每周快照保留几周，最后每个卷保留一个月的快照，甚至更less，这取决于保留时间政策。 （我的自动化使用卷上的“魔术”标签来自定义每卷级别的保留和时间，但是大多数卷使用默认策略。）
顺便说一下，在S3的讨论中，可能有一点需要澄清，EBS是S3的“客户”，而不是你 – 这就是为什么你不能在S3中看到这个备份数据。
¹ “无论块的粒度是多less” – 由此，我的意思是从EBS的angular度来看“备份块”的大小。 就我所知，这个大小是没有logging的，但是我的假设是，在这种情况下，“块”几乎肯定大于提供给操作系统的设备的“块大小”，因为备份块大小一位数的KiB将导致大量的块进行杂耍，跟踪，存储和重新加载。