首先，我如何检索我的EBS快照消耗的空间？
其次，根据文档，Amazon EBS快照仅备份自上次创build快照以来已修改的EBS卷的块。 假设我有一个10GB的EBS卷。 我为它创build了第一个快照。 由于没有“最后”快照，我假设第一个快照的大小是10GB。 好。 然后我修改了1GB的数据并创build了第二个快照。 第二个快照的大小应该在1GB左右，对吧？ 但是，如果我现在删除了第一个快照呢？ 第二个快照仍然是1GB？ 如果是的话，我还能从第二张快照中恢复10GB的EBS卷吗？ 还是第二个快照自动成为10GB？
这可能会回答Q2（ http://aws.amazon.com/ebs/ ）：
即使快照是以增量方式保存的，但在删除快照时，只会删除其他任何快照不需要的数据。 因此，无论先前哪个快照已被删除，所有活动的快照都将包含恢复该卷所需的全部信息
在你的例子中，在删除第一个快照之后，你将不会再支付第一个快照覆盖的第一个快照中的1GB，你将无法恢复第一个快照的状态。
但是对于一组快照在S3使用方面的成本还是非常不透明的。
看到这个消息和它下面的回复两条消息。 本质上，每个块只有一个副本，多个快照可以引用同一个块。 可以按任意顺序删除快照，并且可以使用任何快照将卷恢复到创build快照时的状态。
快照包含我相信只有至less被写入一次的块。 因此，如果您创build了一个新的EBS，然后使用某种“快速”格式进行格式化，只是写入文件分配表，那么我认为只有文件分配表使用的块才会写入初始快照。
将EBS用于数据库存储时，可能会考虑在使用数据库之前初始化整个EBS，这似乎会加快数据库的速度，因为该驱动器已经完全初始化。 缺点是这意味着初始快照可能是整个EBS驱动器，即10GB。
不pipe亚马逊
首先有两种types的快照。 一个是Full，另一个是Incremental。 在你的例子中，你提到10GB和1GB，所以你可以猜测哪个是哪个。 如果没有完整的快照，则不可能完全恢复数据。 增量快照是节省空间和时间的一种方法，以免一次又一次地备份整个图像。 所以虽然你可以保留零增量快照，你必须有ATLEAST一个完整的快照。
The restore is done in the following way. 1. get the Latest FULL snap 2. Is there any more incremental snap since the last full backup? yes 2.1 Apply the incremental changes in order from the last full backup to the latest | END no 2.2 END 因此，你可以计划你需要多less。 也许每周进行一次完整备份，每天进行一次？ 或任何适合你的情况。 然而亚马逊在这里有点不同
至于亚马逊似乎假设的成本（为了简单起见）
- 整个EBS是快照（不是一个真正的词，我只是补充），包括自由空间。
- 另外，压缩不算，如果他们压缩它仍然没有考虑在这里。
- 一个完整的快照或增量将全部进入S3未压缩，所以你会支付S3存储和传输
- 完整的快照更像是一个AMI。 所以你最好使用AMI，因为AMI似乎没有包含图像大小的未使用空间，因此S3存储的要求较小。
- 正如其他人所提到的那样，Amazon通过确保删除快照不会影响恢复，从而防止用户删除错误的快照。 我认为他们内部化的过程中，他们将增量捕捉应用到完整的捕捉，并显示为删除。 他们>仍然存储整个EBS卷一次
现在我不是AWS的专家，但这是我的理解。 我可能是错的