AWS 不能压缩快照（对于包含二进制数据的 EBS）吗？答案

【问题标题】：Can AWS not compress snapshots (for EBS containing binary data)?AWS 不能压缩快照（对于包含二进制数据的 EBS）吗？
【发布时间】：2018-03-22 16:42:19
【问题描述】：

我正在使用 Scheduled Cron 表达式规则创建我的 EBS 卷的定期快照（感谢 John C）。

我的数据都是二进制，，我怀疑 AWS 对我的数据执行的自动压缩 - 实际上会放大生成的快照。

有没有办法指示 AWS 在创建快照时不使用压缩（这样我就可以比较压缩/不压缩的快照大小）？

注意：
Creating an Amazon EBS Snapshot 似乎表明使用压缩是强制性的。

【问题讨论】：

您是否见过快照实际上更大的情况？
了解快照实际大小的唯一方法（afaik）是通过daily cost and usage report。将成本除以费率以确定存储了多少。删除同一卷的旧快照，您将观察到下一个最新快照的成本增加了您通过删除消除的成本的一部分，因为成本被重新分配。您还将看到完全未更改的卷的更新快照，无需任何成本。我无法想象你多付了钱。
我不确定我是否可以在无法停止 AWS 自动压缩的情况下进行测试，@jarmod。但是，作为一般规则，由于压缩会在维护其表和指针时产生开销，如果我的数据是二进制的，这在 AWS 看来就像一个随机流，那么几乎按照定义，“压缩”数据将比未压缩数据占用更多空间数据。
哇。现在是复杂的。谢谢，@Michael。
二进制数据不一定意味着“不可压缩”。

【解决方案1】：

您无法控制用于 EBS 快照的压缩。

EBS 快照是增量的（第一个快照除外）。该数据是根据 AWS 自己的启发式方法进行压缩的。您无法看到实际压缩数据的大小。

当您查看 EBS 快照时，快照的“大小”将始终报告为原始 EBS 卷的大小，无论快照的实际大小如何。

【讨论】：

【解决方案2】：

我认为 EBS 快照现在没有被压缩（我不确定它们是否更早），而且我在 AWS 文档中也找不到任何关于压缩的参考。这就是为什么初始快照的大小与卷的大小相同的原因。在第一个快照之后，其他快照是增量的，因此只有设备上在最后一个快照之后更改或添加的块会保存在新快照中。

您可以参考博客了解ebs snapshots backup & restore 的工作原理。

【讨论】：