这个问题有一些有趣的地方-特别是有关停机时间的想法。想法的一部分是，如果应用程序对停机敏感，则还必须考虑恢复时间。（作为一个极端的论点，没有备份不需要停机，除非您碰巧需要这些备份，在这种情况下，停机时间可能会无限长）。
关于EBS的一些知识
EBS卷和快照在块级别上运行-结果是，即使正在使用EBS卷，也允许在实例运行时拍摄快照。但是，快照中仅包括磁盘上实际存在的数据（即不在文件缓存中）。正是后者的原因引起了一致快照的想法。
- 推荐的方法是分离卷，对其进行快照并重新附加它-通常不可行。
- 下一个最佳选择是将写缓存刷新到磁盘，冻结文件系统并拍摄快照
这里有趣的一点是，在上述两种情况下，您都无需等待快照完成重新连接/解冻并恢复写入磁盘的操作-快照启动后，您的数据将与该时间点保持一致。通常，只需要几秒钟即可将磁盘写锁定。同样，由于大多数数据库都以合理的方式在磁盘上构造其文件-插入对现有块的影响很小，这很有可能-从而最大程度地减少了添加到快照的数据。
考虑备份点
EBS卷已经在可用区域中进行了复制-因此内置了一定程度的冗余。如果您的实例终止，则可以简单地将EBS卷附加到新实例，然后（在克服一致性不足之后）在您的位置继续离开。在许多方面，这使EBS卷非常像一个不一致的快照，只要您可以访问它即可。就是说，大多数EC2用户很可能会回忆起2011年初EBS卷的级联故障-卷连续几天无法访问，并且一些用户也丢失了数据。
RAID1
如果您试图防止EBS磁盘发生故障（确实发生了），则可以考虑使用RAID1设置。由于EBS卷是块设备，因此您可以轻松地使用mdadm在所需的配置中进行设置。如果您的一个EBS卷没有达到规格要求，那么很容易手动使它失效（然后将其替换为另一个EBS卷）。当然，这样做有缺点-每次写入时间增加，对可变性能的敏感性更高，I / O成本增加了一倍（货币化，而不是性能方面），没有针对更广泛的AWS故障的真正保护措施（去年的常见问题是（无法分离处于锁定状态的EBS卷），当然，也包括失败时磁盘的不一致状态。
S3FS
对于某些应用程序（对于数据库绝对不是）的一种选择是将S3挂载为本地文件系统（例如，通过s3fs）。这很慢，缺少文件系统可能会提供的某些功能，并且可能无法达到预期的效果（最终一致性）。就是说，出于简单的目的（例如使上传的文件可跨实例使用），它可能有优点。显然，它不适合任何需要良好读/写性能的应用。
MySQL bin日志
特定于MySQL的另一种选择可能是使用bin-log。您可以设置第二个EBS卷，该卷将存储您的bin日志（以最大程度地减少添加的写操作对数据库的影响），并将其与您进行的任何数据库转储结合使用。您甚至可以使用s3fs来做到这一点，如果性能可以容忍，它实际上可能会有好处（尽管rsync可能比尝试直接使用s3fs更好，并且您肯定会压缩自己的能力）。
但是，我们再次回到目的的概念。考虑以上建议会发生什么：
- 无法访问EBS卷：
- RAID1-无用，因为您无法获取数据
- bin-log-无用，除非您将其导出到S3-否则可能会延迟
- 实例意外终止：
- RAID1-您的磁盘可用，但不一致，数据库可能会自行从不一致中恢复
- bin-log-您的数据应该可以访问，尽管您可能需要查看最近的一些事件
- 有人以root身份运行DROP DATABASE：
- RAID1-您有一个不存在的数据库的两个完美副本
- bin-log-您应该能够在命令之前重播事件，所以您应该没问题
因此，实际上，RAID1几乎没有用，bin-log花费的时间太长-两者在某些情况下可能都有优点，但与备份的想法相去甚远。
快照
重要的是要注意快照是差异的，并且仅存储包含数据（并经过压缩）的实际块。与EBS卷不同，在EBS卷中，如果您有20GB的卷，但仅使用1GB，则仍然需要为“预配置”存储（20GB）付费。使用快照，您只需为使用的内容付费。如果快照之间没有数据更改，则（理论上）不收费。（快照是为PUTS / GETS和使用的存储收费的）。
顺便说一句，我强烈建议您不要将应用程序数据（包括数据库）存储在根卷（您可能已经设置了）上。优点之一是，希望您的根卷可以看到最少的更改-这意味着其快照快照的频率可能较低（或更改最少），从而降低了成本并易于使用。
值得一提的是，您可以随时删除旧快照-即使它们不同，它们也不会影响其他快照。也就是说，分配给快照的每个块都不会放弃，直到没有快照仍引用该块为止。
定期转储的问题首先是转储之间的时间（可能是通过使用MySQL的bin-log解决的）以及恢复的难度。导入大型转储并重播bin日志中的所有事件需要花费时间。同样，创建转储并非没有性能影响。可以说，此类转储可能需要比快照更多的存储空间。仅为数据库设置EBS卷并进行快照，这在大多数方面都比较可取（也就是说，进行快照的确对性能有一点影响）。
快照和EBS卷的优点在于可以在其他实例上使用它们。如果您的实例无法启动，则可以将根卷附加到另一个实例以诊断并解决问题-或仅从中复制数据-并可以在几分钟的停机时间内切换根卷（停止实例，分离根卷，附加一个新的根卷，启动实例）。同样的想法适用于将数据存储在第二个EBS卷上。本质上，您只是从自定义AMI中启动一个新实例，然后将当前EBS卷附加到该实例上-这有助于最大程度地减少停机时间。
（一个人可能会提出这样的论点（我可能不会推荐）：您可以使用两个EBS卷在同一服务器（主-从）上设置MySQL的两个副本，然后关闭从属以对其快照进行快照EBS的数量-保持一致，没有停机时间-但性能成本可能不值得）。
AWS确实具有自动缩放功能-它将能够维持恒定数量的实例（即使该数量为1）-但是您可以从快照进行部署-因此，如果您的快照没有用，那么前提就没有多大用处。
还有两点-您可以从单个快照中部署任意数量的实例（与EBS卷不同，EBS卷在任何给定时间只能附加到单个实例）。此外，EBS卷仅限在可用区域内使用，而快照可以在区域内使用。
理想情况下，使用快照，如果服务器发生故障，则可以使用上一个快照启动一个新快照-特别是如果您将根卷与数据分开，则错误的更新应将停机时间降到最低（因为跨传输包含您的数据的EBS卷-并对其进行快照以保留可能由于不一致而损坏的任何内容。
附带说明，Amazon指出，自上次快照以来，EBS卷的故障率随其上更改的数据量而增加。
最终建议
- 使用快照-很棒-减少停机时间远比造成快照多
- 将数据和根卷分开，甚至可能将数据库放在自己的卷上，并在必要时在更新之前进行快照
- 使用bin日志保持尽可能“热”-将其（压缩的）上传到S3
- 确保实际从实例中获取数据（即使EBS卷上的数据完整无缺，该卷本身也可能暂时无法访问）。
推荐读物：
（我确实相信我写的太多了，但还不够多-但希望您能找到值得阅读的内容）。