Bar*_*rim 9 linux backup amazon-ec2
已经提出了类似的问题，但我需要知道在这种情况下会推荐什么，以了解我对使用 EC2 的理解是否遗漏了什么。
一家小型初创公司正在 EC2 网络上开展业务，并向我询问有关备份选项的一些建议。他们目前是自筹资金，并在可行的情况下尽其所能节省成本。在不深入研究他们系统配置的情况下，我将举一个 web 服务器作为例子；它是一个带有数据库的简单 Web 服务器。问题是他们不希望服务器被关闭。
一直在进行设置的人认为，他们应该只是定期转储数据库并将其存储在 S3 上，或者创建脚本，以便在需要时通过备份保存配置信息的选定文件夹在 Amazon 上重建新服务器. 他建议创建服务器的快照会很浪费，因为它们会占用大量磁盘空间，并且基本上会在大型数据转储之间存在数据腐烂，因此快照会很快过时。
我的想法是拍摄 VM 的快照，然后定期转储数据库并存储在 S3 中。如果他们丢失了 EC2 实例或有诸如更新之类的事情使其无法使用，他们可以使用快照来使用最新的数据库转储相对快速地构建服务器备份，而不是从头开始构建一个新实例。新的 AMI。
我的理解是，拍摄 EC2 实例（或 EBS 存储）的快照需要停机，而他们对此犹豫不决。我还读到您应该关闭服务器以在拍摄快照时保持文件系统一致。由于它们在平衡器后面还没有集群，因此限制了涉及快照的选项。
除非有我不知道的特定于 Amazon 的东西，否则构建服务器的脚本将涉及创建一个 Chef 或 Puppet 服务器，这些服务器可以在 EC2 上部署具有关联角色的新服务器。现在，这家初创公司没有资金来维持这种服务器的运转，而且他们现在真的不需要部署那么多服务器。
理想情况下，他们将有资金在虚拟平衡器或亚马逊的平衡器服务后面创建多个服务器，然后一次关闭服务器以执行更新或快照。现在我对进行更新的想法感到紧张，因为如果您正在执行数据库转储，那么如果系统更新更改了他们的应用程序所依赖的库并且服务出现故障，那将无济于事。
我还假设另一个选择是运行一个脚本来创建一个 EBS 卷，挂载它，然后在服务器上运行类似 rsync 的东西来捕获大部分文件系统信息到 EBS 卷，然后压缩并将内容复制到 S3，断开卷并销毁它以节省存储成本，然后进行数据库转储以捕获在其他情况下不一致的动态数据。对于他们的某些服务器，随着数据库需求的增长，很可能需要将其保存到临时 EBS 卷。
正在创建一个 VMWare 沙箱，以在可以预先测试更新的环境中重新创建他们的网络系统，然后再将它们应用于 Amazon 上的生产系统。我希望这将最大限度地减少系统更新杀死他们的应用程序的可能性。
所以......考虑到运行一台服务器的限制，系统上有数据库和应用程序服务器，希望尽可能接近没有停机时间（限制使用快照并使备份过程尽可能“热”（在不关闭服务器的情况下实时创建），我是否建议安排时间在其工作状态下创建 EC2 实例的快照并从那里进行数据库转储以复制到 S3？是否有更好的策略可以追求？在创建服务器的实时备份时，快照是否会造成停机？
cyb*_*x86 18
这个问题有一些有趣的地方——特别是关于停机时间的想法。部分想法是，如果应用程序对停机时间很敏感，那么还必须考虑恢复时间。（作为一个极端的论点，没有备份不需要停机时间，除非您碰巧需要这些备份，在这种情况下停机时间可能接近无穷大）。
关于 EBS
EBS 卷和快照在块级别运行 - 其结果是允许在实例运行时拍摄快照，即使 EBS 卷正在使用中。但是，只有实际在磁盘上（即不在文件缓存中）的数据才会包含在快照中。正是后一个原因产生了一致快照的想法。
这里有趣的一点是，在上述两种情况下，您无需等待快照完成重新附加/解冻并继续写入磁盘 - 一旦启动快照，您的数据将与该时间点保持一致。通常，这仅需要几秒钟的时间，在此期间您的磁盘被写锁定。此外，由于大多数数据库以合理的方式在磁盘上构建它们的文件 - 插入对现有块的影响很小 - 这最大限度地减少了添加到快照的数据。
考虑备份点
EBS 卷已在可用区中复制 - 因此内置了一定程度的冗余。如果您的实例终止，您只需将 EBS 卷附加到新实例，然后（在您克服缺乏一致性之后）从您所在的位置继续离开了。在许多方面，这使得 EBS 卷很像一个不一致的快照，前提是您可以访问它。也就是说，大多数 EC2 用户可能还记得 2011 年初 EBS 卷的级联故障 - 卷数天无法访问，一些用户也丢失了数据。
RAID1
如果您试图防止 EBS 磁盘出现故障（它确实发生），您可以考虑使用 RAID1 设置。由于 EBS 卷是块设备，因此您可以轻松地使用 mdadm 将它们设置为所需的配置。如果您的一个 EBS 卷不符合规范，很容易手动使其失败（然后用另一个 EBS 卷替换它）。当然，这也有缺点 - 每次写入的时间增加，对可变性能的影响更大，I/O 成本加倍（货币，而不是性能方面），无法真正保护更广泛的 AWS 故障（去年的一个常见问题是无法分离处于锁定状态的 EBS 卷），当然还有磁盘出现故障时的不一致状态。
S3FS
某些应用程序（绝对不是数据库）的一个选项是将 S3 挂载为本地文件系统（例如，通过 s3fs）。这很慢，缺乏人们期望从文件系统中获得的一些功能，并且可能不会按预期运行（最终一致性）。也就是说，对于一个简单的目的，比如让上传的文件跨实例可用，它可能有好处。显然，它不适用于需要良好读/写性能的任何东西。
MySQL 二进制日志
另一个特定于 MySQL 的选项可能是使用 bin-log。您可以设置第二个 EBS 卷来存储您的二进制日志（以最小化添加的写入对数据库的影响），并将其与您进行的任何数据库转储结合使用。您甚至可以使用 s3fs 来做到这一点，如果性能可以忍受，这实际上可能是有价值的（尽管 rsync 可能比尝试直接使用 s3fs 更好，而且您肯定希望压缩您所能做的）。
不过，我们再一次回到目的的概念。考虑一下上述建议会发生什么：
所以说真的，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 卷的故障率会随着自上次快照以来更改的数据量而增加。
最终建议
推荐阅读：
（我确实相信我写了太多，但说得还不够多——但希望你能找到值得一读的东西）。