我们需要在AWS上执行MongoDB备份的频率如何？

Question

我开始分析MongoDB如何在Amazon AWS上运行，我觉得我在这里缺少一些基本的东西。从我在亚马逊存储文档上看到的内容来看，亚马逊似乎会自动对其硬件磁盘进行一些备份。因此，如果他们能够透明地恢复每个磁盘（存储MongoDB数据），那么我还需要关心备份和恢复吗？

我最感兴趣的是灾难或故障恢复问题，但它与硬件故障有关，而且目前还不清楚亚马逊是否已经自动处理（使用磁盘镜像或预定义的备份计划），或者我们仍然需要手动执行（锁定，备份） ，然后恢复某一天）？如果没有那么当某些磁盘在AWS上出现故障时会发生什么数据是否被破坏（网站损坏且部分功能），我们在晚上收到来自AWS的电子邮件，然后我们需要在早上立即恢复（收到电子邮件后）数据库？ ：）

Answer 1

我认为你的分析是基于错误的，即使不是危险的假设。一些基础知识：

1. 备份间隔首先由最坏情况下可接受的数据丢失确定。
2. 确保AWS（或MongoDB）提供的数据可用性的方法不能替代备份。例如，如果数据因DBA错误而丢失，则磁盘镜像无效。
3. 备份间隔和方法应该反映您的（内部？）SLA。

我是这样做的。简化，详细分析需要了解用例，每小时停机时间的直接和间接成本以及其他一些因素。

1. 找出营业额/ h。
2. 找到尽可能多的恢复方法。对于MongoDB，最突出的是mongodump（我很少使用，如果，仅适用于非常小的数据库），磁盘快照（我更喜欢使用LVM）和MMS backups。
3. 为您选择的每种方法制定最具时效的恢复计划。
4. 使用最差情况（完全丢失数据，MongoDB和 - 以及 - 如果适用 - 其他应用程序数据）测试这些计划，并在必要时进行优化。
5. 选择恢复时间（考虑您的SLA）和可接受成本之间的最佳平衡。可接受的成本/年是您愿意为备份花费的营业额的一小部分，加上估计的停机时间（保守，我通常会修改当前值至少1.5），包括h /年的恢复乘以营业额/ h。请记住，使用副本集和负载平衡的前端可以彻底减少您的整体停机时间，同时提供其他好处。

上述备份方法之间的一个小比较：

mongodump

一个漂亮的工具，它允许您创建远程机器的备份，这是一个优势，因为您不必手动从数据承载机器移动数据，并且您不需要额外配置该机器上的磁盘空间。它的缺点是恢复非常慢。 MongoDB建议只在小型数据库上使用mongodump，我只能说它。至于定义小，我个人画了大约1GB的行。

LVM快照

如果操作正确，此方法非常灵活 - 您可以对MongoDB数据和其他应用程序数据（如文件）进行一致备份，例如一步完成，从中创建压缩的tar文件，通过非常简单的shell脚本将其存储在非现场位置。缺点是您需要过度配置磁盘，压缩需要时间和资源，您需要了解自己在做什么。

彩信备份

这是法拉利的MongoDB备份方法 - 它提供实时备份和按时间点恢复，设置和恢复非常简单......但是，它带有相当大的价格标签，甚至更多在AWS中，因为数据被发送（当然是加密的）到MMS，这应该算作外部流量。但是，我仍然建议在AWS上使用MMS：任何与金融交易（商业意义上的）或极其严格的SLA直接相关的内容都应使用MMS，因为它提供了真正的时间点恢复