有人问过类似的问题，但我需要知道在这种情况下会推荐什么，以了解我是否在使用 EC2 的理解中遗漏了某些东西。
一家小型初创公司在 EC2 网络上开展业务，并向我咨询了一些有关备份选项的建议。他们目前是自筹资金，正在尽其所能节省成本。我不会过多地介绍他们的系统配置，我以一个 Web 服务器为例；这是一个带有数据库的简单 Web 服务器。问题是他们不想让服务器瘫痪。
负责设置的人认为，他们应该定期转储数据库并将其存储在 S3 上，或者创建脚本，在需要时通过备份保存配置信息的选定文件夹来重建 Amazon 上的新服务器。他认为创建服务器快照是一种浪费，因为它们占用大量磁盘空间，而且大量数据转储之间本质上会有数据腐烂，因此快照很快就会过时。
我的想法是拍摄虚拟机的快照，然后定期转储数据库并存储在 S3 中。如果他们丢失了 EC2 实例，或者由于更新等原因导致实例无法使用，他们可以使用快照以最新的数据库转储相对快速地重建服务器，而不是从头开始从全新的 AMI 构建新实例。
我的理解是，拍摄 EC2 实例（或 EBS 存储）的快照需要停机，这是他们不愿意看到的。我还读到，拍摄快照时，应该关闭服务器以保持文件系统的一致性。由于他们还没有平衡器后面的集群，因此这些限制了涉及快照的选项。
编写脚本构建服务器（除非 Amazon 有我不知道的具体内容）需要创建 Chef 或 Puppet 服务器，该服务器可以在 EC2 上部署新服务器及其相关角色。目前，这家初创公司没有资金来维持这种服务器，而且他们目前确实不需要部署那么多服务器。
理想情况下，他们会有足够的资金在虚拟平衡器或亚马逊的平衡器服务背后创建大量服务器，然后一次关闭一台服务器以执行更新或快照。现在，我对进行更新的想法感到紧张，因为如果你正在转储数据库，那么如果系统更新改变了应用程序所依赖的库并且服务中断，这将无济于事。
我还认为另一个选择是运行一个脚本来创建一个 EBS 卷，安装它，然后在服务器上运行类似 rsync 的程序来将大部分文件系统信息捕获到 EBS 卷中，然后压缩并将内容复制到 S3，断开卷连接并销毁它以节省存储成本，然后执行数据库转储以捕获否则会不一致的动态数据。对于他们的一些服务器，随着数据库需求的增长，很可能有必要将数据保存到临时 EBS 卷中。
正在创建 VMWare 沙盒，以便在将更新应用到 Amazon 的生产系统之前对其进行预先测试的环境中重新创建他们的网络系统。我希望这可以最大限度地降低系统更新杀死其应用程序的可能性。
所以......考虑到运行一台服务器的限制，系统上有数据库和应用程序服务器，希望尽可能接近没有停机时间（限制使用快照并使备份过程尽可能“热”（在不关闭服务器的情况下实时创建），我建议安排时间在工作状态下创建 EC2 实例的快照，然后从那里进行数据库转储以复制到 S3，这样是不是错了？如果快照会导致停机，在创建服务器的实时备份时是否有更好的策略？
答案1
这个问题有一些有趣的地方 - 特别是关于停机时间的概念。部分想法是，如果应用程序对停机时间很敏感，那么恢复时间也必须考虑在内。（作为一个极端的论点，没有备份就不需要停机时间，除非你恰好需要这些备份，在这种情况下停机时间可能会接近无穷大）。
关于 EBS
EBS 卷和快照在块级别运行 - 因此允许在实例运行时拍摄快照，即使 EBS 卷正在使用中。但是，只有实际位于磁盘上（即不在文件缓存中）的数据才会包含在快照中。正是后一个原因产生了一致性快照的想法。
- 推荐的方法是分离卷，对其进行快照，然后重新连接 - 通常不切实际。
- 下一个最佳选择是将写缓存刷新到磁盘，冻结文件系统，并拍摄快照
这里有趣的一点是，在上述两种情况下，您无需等待快照完成即可重新连接/解冻并恢复写入磁盘 - 一旦启动快照，您的数据将与该时间点保持一致。通常，这只需要几秒钟，在此期间您的磁盘处于写锁定状态。此外，由于大多数数据库以合理的方式在磁盘上构建文件 - 插入对现有块的影响很小 - 从而最大限度地减少了添加到快照的数据。
考虑备份的要点
EBS 卷已在可用区域内复制 - 因此内置了一定程度的冗余。如果您的实例终止，您可以简单地将 EBS 卷附加到新实例，然后（在您克服缺乏一致性的问题后）从上次中断的地方恢复。在许多方面，这使得 EBS 卷非常像不一致的快照，前提是您可以访问它。话虽如此，大多数 EC2 用户可能还记得 2011 年初 EBS 卷的连锁故障 - 卷无法访问数天，一些用户还丢失了数据。
RAID1
如果您试图防止 EBS 磁盘发生故障（确实会发生），您可以考虑使用 RAID1 设置。由于 EBS 卷是块设备，因此您可以轻松地使用 mdadm 将它们设置为所需的配置。如果您的某个 EBS 卷未按规格执行，则很容易手动使其发生故障（稍后用另一个 EBS 卷替换它）。当然，这有缺点 - 每次写入的时间增加，更容易受到可变性能的影响，I/O 成本增加一倍（金钱方面，而不是性能方面），无法真正防止更广泛的 AWS 故障（去年常见的问题是无法分离处于锁定状态的 EBS 卷），当然，磁盘在发生故障时状态不一致。
S3FS
对于某些应用程序（绝对不是数据库）来说，一种选择是将 S3 安装为本地文件系统（例如通过 s3fs）。这种方法速度很慢，缺少文件系统所具有的一些功能，并且可能无法按预期运行（最终一致性）。话虽如此，但对于使上传的文件跨实例可用这样的简单目的，它可能有其优点。显然，它不适用于需要良好读/写性能的任何事情。
MySQL binlog 日志
MySQL 特有的另一个选项可能是使用 bin-log。您可以设置第二个 EBS 卷来存储 bin-log（以尽量减少对数据库的额外写入的影响），并将其与您进行的任何数据库转储结合使用。您甚至可以使用 s3fs 来做到这一点，如果性能可以接受，这实际上可能有好处（不过，rsync 可能比直接使用 s3fs 更好，而且您肯定会希望尽可能地压缩）。
不过，我们再次回到目的这个话题。考虑一下上述建议会带来什么结果：
- EBS 卷无法访问：
- RAID1 - 无用，因为你无法获取数据
- bin-log - 无用，除非你将其导出到 S3 - 但如果你这样做的话可能会有延迟
- 实例意外终止：
- RAID1 - 您的磁盘可用，但不一致，您的数据库可能会自行从不一致中恢复
- bin-log - 你的数据应该是可访问的，尽管你可能需要查看最近的几个事件
- 有人以 root 身份运行 DROP DATABASE：
- RAID1 - 您拥有不存在的数据库的两个完美副本
- bin-log - 你应该能够重播命令执行之前的事件，所以你应该没问题
因此实际上，RAID1 基本上是无用的，而 bin-log 耗时太长——两者在某些情况下可能都有优点，但远非理想的备份。
快照
需要注意的是，快照是不同的，只存储包含数据的实际块（并经过压缩）。与 EBS 卷不同，如果您有 20GB 的卷，但只使用了 1GB，您仍然需要为“预配置”存储（20GB）付费。使用快照，您只需为您使用的内容付费。如果快照之间没有数据变化，则（理论上）不收费。（快照会因 PUTS/GETS 和使用的存储而收费）。
另外，我强烈建议不要将应用程序数据（包括数据库）存储在根卷上（您可能已经设置了根卷）。这样做的一个优点是，希望您的根卷发生的变化最少 - 这意味着其快照可以不那么频繁（或变化最少），从而降低成本和易用性。
值得一提的是，您可以随时删除旧快照 - 即使它们是不同的，也不会影响其他快照。也就是说，分配给快照的每个块都不会被放弃，直到没有快照仍然引用该块。
定期转储的问题首先是转储之间的时间（可能通过使用 MySQL 的 bin-log 来解决），其次是恢复的难度。导入大型转储并重放 bin-log 中的所有事件需要时间。此外，创建转储并非没有性能影响。可以说，此类转储可能需要比快照多得多的存储空间。为数据库单独设置 EBS 卷并对其进行快照在大多数情况下都是可取的（也就是说，拍摄快照也会对性能产生一些影响）。
快照和 EBS 卷的优点在于它们可用于其他实例。如果您的实例无法启动，您可以将根卷附加到另一个实例以诊断和修复问题 - 或者只是从中复制数据 - 并且可以在停机几分钟内切换根卷（停止实例，分离根卷，附加新的根卷，启动实例）。同样的想法也适用于将数据放在第二个 EBS 卷上。本质上，您只需从自定义 AMI 启动一个新实例，并将当前的 EBS 卷附加到它 - 它有助于最大限度地减少停机时间。
（有人可能会提出这样的论点（我可能不会推荐这样做），你可以在同一个服务器（主从）上设置两个 MySQL 副本，使用两个 EBS 卷，然后关闭从属服务器以获取其 EBS 卷的快照 - 它将保持一致，没有停机时间 - 但性能成本可能不值得）。
AWS 确实具有自动扩展功能 - 它将能够维持恒定数量的实例（即使该数字是 1） - 但是您可以从快照中进行部署 - 因此，如果您的快照没有用，那么前提就没有多大用处。
另外几点 - 您可以从单个快照部署任意数量的实例（与 EBS 卷不同，EBS 卷在任何给定时间只能附加到单个实例）。此外，EBS 卷仅限于在可用区域内使用，而快照可以在区域内使用。
理想情况下，有了快照，如果您的服务器出现故障，您只需使用最后一个快照启动一个新服务器 - 特别是如果您将根卷与数据分开，错误的更新会导致最短的停机时间（因为您只需传输包含数据的EBS卷 - 并对其进行快照以保留可能由于不一致而损坏的任何内容）。
附注：亚马逊表示，自上次快照以来，EBS 卷上的数据更改量增加，其故障率也会随之增加。
最后建议
- 使用快照 - 它们很棒 - 它们减少的停机时间远远大于导致停机的时间
- 分离数据和根卷，甚至可以将数据库放在自己的卷上，并在必要时在更新之前进行快照
- 使用 bin-log 尽可能保持“热度” - 将其（压缩）上传到 S3
- 确保您确实从实例中获取了数据（即使 EBS 卷上的数据是完整的，卷本身也可能暂时无法访问）。
推荐阅读：
（我确实认为我写得太多了，但说的还不够——但希望你能找到一些值得一读的东西）。
答案2
可以对实时 EBS 卷进行快照但是，您必须小心确保文件系统处于一致状态，然后在启动快照时冻结。并非所有文件系统都允许这样做，但这绝对是可能的，也是我们自己的备份解决方案的基础。
EBS 快照也相当便宜，因为它们只对更改的数据收费，而且数据费用本身非常合理。但请记住，这是基于块级更改，因此变化相当快。快照之间也是如此，只有快照之间更改的数据才会收费。为了让您了解成本，我们每月支付不到 10 美元的快照存储费用，我们每天拍摄快照，保留最近 7 天的每日快照和上个月的每周快照，我们有 2 台服务器遵循此方案（约 20 个快照，20GB 硬盘）。
答案3
像 Zmanda Cloud Backup 这样的廉价备份解决方案怎么样？我们使用它来备份大约 6 台服务器和 1 台 SQL Server，每月只需 10 美元左右。您可以使用自签名证书加密数据，他们使用 s3 来存储数据（因此如果您从 EC2 备份，则无需支付数据传输费用）。