我正在定期拍摄 1TB EBS（Amazon Web Services Elastic Block Store）卷的快照作为备份。如果整个 AZ（可用区）不可用，我的灾难恢复计划是从同一区域的另一个 AZ 中的最新快照创建新的 EBS 卷。
我如何确定创建新的 EBS 卷需要多长时间？我的 RTO（恢复时间目标）为 6 小时。我可以用这种方法满足要求吗？
它可能不应该/没有任何区别，但我在 ap-southeast-2 地区（即悉尼）。
答案1
我如何确定创建新的 EBS 卷需要多长时间？
创建一个。
然后，尝试使用它。在几个小时和几天内继续使用它，并记录你观察到的情况。
对你的问题的第一个回答是它实际上只需要几秒钟。
这个答案的问题在于它没有讲述整个故事：
从现有 EBS 快照创建的新卷在后台延迟加载。这意味着，从快照创建卷后，无需等待所有数据从 Amazon S3 传输到您的 EBS 卷，然后附加的实例就可以开始访问卷及其所有数据。如果您的实例访问尚未加载的数据，卷会立即从 Amazon S3 下载请求的数据，并继续在后台加载其余数据。
但是，您必须了解这里的“立即”一词的含义。立即并不意味着音量最初和最终一样快。请记住：微秒和毫秒之间的差异直观上似乎很小，但它仍然是 1,000 倍。
[...] 必须先初始化从快照恢复的卷上的存储块（从 Amazon S3 中拉下并写入卷），然后才能访问该块。
这个初步行动需要时间，并且可能会导致第一次访问每个块时 I/O 操作的延迟显著增加。
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html
这就是我上面的观点——创建卷只需要几秒钟，此时它是可用的，但很慢。
EBS 卷是逻辑实体。从快照还原卷时，卷上的每个块都是逻辑上现在和逻辑上新卷一发行，即可购买，但不一定身体上首次尝试读取时，该卷上会出现该信息。
总体而言，为了立即使用卷上任何位置的任何特定块，加载块的延迟只是一个小小的代价，但其影响可能很大，而这种影响的大小在一定程度上取决于卷的使用方式。
dd上面的链接继续解释了如何使用或来加速预热过程fio。文档忽略了一点，即您可以在只读模式下使用其中任何一个已安装卷，并在为操作做好准备的同时获得即时可用性的好处。这将对初始随机访问产生进一步的负面影响，但痛苦会比你什么都不做更快结束，因此这可能是你最好的选择……但你必须对你的 DR 方案进行测试，观察其操作，并相应地调整你的策略。
答案2
和往常一样，Michael 对你的问题给出了很好的回答。你还可以预热卷，这需要一点时间，但可以更快地将所有块导入，因此你可以预先承受性能损失。在另一个可用区中启动实例可能可以通过某种事件、lambda 和 CloudFormation 或 Opsworks 的组合来编写脚本，尽管这需要一些实验。但这不是 AWS 通常的做法。
另一个可能更好的选择取决于您的使用情况和预算，即使用具有自动扩展和多个较小实例的弹性负载均衡器，将您的流量分散到两个或更多可用区。这意味着，如果一个可用区发生故障，您的其他实例将继续提供流量，并且您的 ELB/AS 将自动在可用的可用区中创建更多实例。一旦第一个可用区恢复，它最终将再次平衡所有可用区的负载。
如果您的应用程序在两个较小的实例上运行效果与在单个大型实例上运行效果一样好，那么 ELB 的成本会略高一些，RTO 为零。如果价格比可用性更重要，那么您可能希望遵循原始计划和原始 RTO。
请注意，快照位于一个区域内，跨可用区。如果整个区域都出现问题，您将无法从其他区域访问它们。
答案3
创建 EBS 快照主要取决于卷，以及磁盘上发生的读/写、网络延迟（影响较小）。我个人不建议将 EBS 根卷快照作为备份，因为存在操作系统问题。如果卷是数据磁盘，是的，您可以使用快照作为备份。
我相信您的 RTO 应该足以恢复容量。