我正在使用一个系统，该系统会为其众多 (40) 个卷中的每个卷拍摄一组 42 个轮换的每日 EBS 快照，以用于灾难恢复目的。EBS 卷被聚合到一个 RAID 卷中。通过在拍摄快照期间冻结文件系统来拍摄一组一致的快照。每个单独的卷只有 2 TiB。
在 DR 测试期间，发现将 20+ TiB 的应用程序数据（PostgreSQL 数据库、许多大型表）从快照创建的 EBS 快照支持卷复制到新的非快照卷上需要 24 小时以上。支持的卷。由于 8 个 rsync 同时在不同的子树上工作，因此在副本中具有相当大的并行性。
如果数据没有复制到新的 EBS 卷，那么基于 PostgreSQL 的应用程序会像蜂蜜一样运行很多天，大概直到 EBS 卷的块被弄脏，所以它们现在直接在 EBS 卷上，而不是来自快照。
相比之下，将相同数据从一组非快照支持的 EBS 卷复制到另一个卷只需要几个小时，而使用类似规模的“真实”硬件再次需要的时间要少得多。
为什么我会看到快照支持的卷和普通卷之间存在如此巨大的性能差异？
我的假设是它正在执行写时复制，因此由于必须单独获取快照，因此干净的块不会改变。如果有 40 个快照堆栈支持该卷，那么它可能很难在它出现的最新快照中快速定位块并获取它。
有什么方法可以强制 AWS 从快照中高效且线性地预填充整个新的 EBS 卷，而不是像实际看起来那样进行懒惰的写时复制？
解决此问题的任何其他想法？如果恢复时间超过一天，则一组 DR 快照的用处会大大降低。
从恢复的卷中读取应该足够了。
有趣的是，使用顺序“强制读取”似乎
dd比从文件系统读取产生的更多随机读取性能更好，但你当然可以同时做这两个 - 继续安装它并开始做任何事情您需要这样做，但还需要从块设备中读取和丢弃dd.这种明显的差异是有意义的，特别是如果 EBS 快照基础设施实际上并未将快照块存储在“块”大小（4096 字节）的块中。这似乎是一个非常低效的设计，每兆字节需要数千次操作。
如果您从不同的偏移量开始进行多次顺序读取，它可能会进一步改善恢复。未经测试，但gnu
dd显然可以“跳过”块并开始阅读，而不是从头开始。但是，您绝对不需要创建“新”卷。一旦块被读取加载，它们就“在”EBS 中，而不是来自快照。
有多少快照支持它并不重要。数据不存储在快照“中”。每个快照都包含我随便称为“指针”的所有数据块的完整记录，这些数据块指向包含它的所有数据块（不仅仅是更改的数据块），并且可能存储在快照基础设施使用的后备存储 (S3) 中的位置。
如果您从同一卷中按顺序拍摄快照 A、B 和 C，然后删除快照 B，则所有从 A 更改为 B 但未从 B 更改为 C 的块仍可用于恢复快照 C，但当您删除快照 B 时，它们并没有真正从 B 移动到 C。
当您删除快照时，EBS 会使用引用计数清除不再需要的块的后备存储。没有被任何快照引用的块在后台通过一个多步骤过程进行处理，该过程首先将它们标记为不需要，停止为它们计费，然后在几天后实际删除它们，因为它们是真正的在 refcount = 0 时已确认。 资源。
因此，最初为还原卷贡献块的快照数量不应影响性能。
其他可能有用的信息：以下内容不会改变上述答案的准确性，但在某些情况下可能有价值。
2019 年末，EBS 宣布了一项名为“快速快照还原”的新功能，该功能允许从指定快照在指定可用区创建的卷立即变热，无需预热。
使用信用桶并基于指定快照的大小（即，从中获取它的磁盘卷的大小）——而不是目标卷的大小（可以大于快照的大小）——这功能允许您每小时创建 1024G/大小的卷，因此 128 GiB 快照可以每小时创建 8 个预热卷。随着快照变小，每个可用区每个快照每小时可以创建的卷数上限为 10。
该服务也非常昂贵——每个快照、每个可用区（！？）每小时 0.75 美元——但是，这可能不是您需要持续运行的东西，从这个角度来看，它似乎具有一些潜在价值.
当您激活该功能时，服务API 可以告诉您它何时真正可以使用，并且每 TiB 60 分钟是“优化快照”的规定时间表（从字里行间看，这意味着构建和预热隐藏的主快照中的 EBS 中的卷，随后将由服务克隆以创建额外的 EBS 卷；该功能似乎仅在此阶段完成后才真正可用，并且在此之前从同一快照创建的卷只是普通卷）。
只要您有时间等待“优化”阶段，并且当您不再需要它时终止快速恢复行为的流程到位（以避免非常大的意外计费费用），这似乎确实适用于有限的用例。