我是否可以制作EBS卷的真正增量跨区域快照副本?

时间:2017-03-02 14:36:15

标签: amazon-web-services amazon-ec2 snapshot amazon-ebs

从阅读文档看,相同卷的快照副本似乎是增量的。但是,当我将该卷的快照复制到另一个区域时,即从us-east-1到us-west-2时,这似乎不是我所看到的,性能明智。

真正喜欢做的事情是创建从直接卷到西部地区的初始快照,但这似乎不是一个选项。所以我必须首先在东方创建一个快照,这个快照的唯一目的是复制到西方。

所以我现在正在做的是

  1. 在东部创建东EBS卷的快照。这表现得好像是增量的,比来自相同大小的不同卷的新原始快照要快得多。
  2. 通过定期轮询新快照ID
  3. 等待此快照完成
  4. 将新快照从东向西复制。这似乎不是表现为增量,每个都需要与原始快照一样多的时间,并且大小相当稳定。
  5. 似乎对我来说是什么样的,因为它不是每次都直接从卷或相同的快照复制,所以西部的快照复制不知道是增量的。

    当然,我也愿意接受我不知道看到我认为我所看到的,并且跨区域快照副本是真正增量的。但是考虑到每次感觉都不需要花费9个小时来完成复制。我读过的大多数文档似乎都是从同一个EBS卷中增加的,而当我对复制到西方的快照进行描述时,它没有提到原始卷ID,而是提到了一个虚拟ID,当然是一个WAD。

    - 有关数据性质的背景资料

    只是一些信息,因为有些人可能想知道我们的副本延长到西部的持续时间有多少数据 - 原始EBS卷是用于存储源代码控制系统的备份的ec2实例的数据量。他们的专有备份工具。

    数据量有一些“供应商快照”,这些快照是使用rsync创建的,因此每个新的“供应商快照”在运行和许多通用之间都有很多硬链接,可能有5%的数据在AWS快照副本之间进行更改 自从我们减少了我们保留的并发备份数量以来,总EBS卷大小为3TB,其中40%是未使用的空间。

1 个答案:

答案 0 :(得分:1)

我回到这个问题并再次挖掘文档。我不知道是否有文档的补充,或者我最初错过了,但现在有文档可以解释它。 要使加密的跨区域快照副本为增量式,您必须使用默认加密密钥。 在实施之后,我们的跨区域副本从4-12小时到10到35分钟之间。为我们的灾难恢复实现合理的RPO更加易于管理。