我开始分析MongoDB在Amazon AWS上的工作方式，我觉得我在这里错过了一些基本的东西。从我在亚马逊存储文档中读到的内容来看，亚马逊似乎会自动对其硬件磁盘进行一些备份。那么，如果他们能够透明地恢复每个磁盘（存储MongoDB数据），那么我还需要关心备份和恢复吗？
我最感兴趣的是灾难或故障恢复问题，但它与硬件故障有关，目前还不清楚 Amazon 是否已经自动处理（使用磁盘镜像或预定义的备份计划），或者我们仍然需要手动执行（锁定、备份，然后有一天恢复）？如果不是，那么当 AWS 上的某些磁盘出现故障时会发生什么？数据是否损坏（网站损坏并部分正常运行），我们在晚上收到来自 AWS 的电子邮件，然后我们需要在早上立即恢复（收到电子邮件后）数据库？:)
我认为你的分析是基于错误的，如果不是危险的假设。一些基础知识：
- 备份间隔首先取决于在最坏情况下可接受的数据丢失。
- 确保AWS（或MongoDB）提供的数据可用性的方法不能替代备份。例如，如果由于 DBA 错误而导致数据丢失，则磁盘镜像无济于事。
- 备份间隔和方法应反映您的（内部？SLA。
这是我的做法。简化，因为详细的分析需要了解用例，每小时停机时间的直接和间接成本以及许多其他因素。
- 找出营业额/小时。
- 找到尽可能多的恢复方法。对于MongoDB，最突出的是mongodump（我很少使用，如果，只用于非常小的数据库），磁盘快照（我更喜欢使用LVM）和MMS备份。
- 为您选择的每种方法制定最省时的恢复计划。
- 使用最坏的情况（MongoDB和其他应用程序数据（如果适用）的数据丢失）测试这些计划，并在必要时对其进行优化。
- 选择在恢复时间（考虑您的 SLA）和可接受成本之间取得最佳平衡的那个。可接受的成本/年是您愿意为备份花费的营业额的一小部分，加上估计的停机时间（保守地说，我通常至少修改当前值为 1.5），包括以小时为单位的恢复乘以营业额/小时。请记住，使用副本集和负载平衡的前端可以大大减少总体停机时间，同时提供其他好处。
上述备份方法之间的一个小比较：
蒙戈垃圾场
一个漂亮的工具，它允许您创建远程机器的备份，这是一个优势，因为您不必手动从数据承载机器移动数据，也不需要在该机器上配置额外的磁盘空间。它的缺点是恢复非常慢。MongoDB建议只在小型数据库上使用mongodump，我只能其次。至于定义小，我个人在大约 1GB 处画了一条线。
LVM 快照
如果做得好，这种方法非常灵活 - 您可以在一个步骤中对MongoDB数据和其他应用程序数据（例如文件）进行一致的备份，从中创建压缩的tar文件并将其存储在非现场位置通过非常简单的shell脚本。缺点是您需要过度配置磁盘，压缩也需要时间和资源，并且您需要了解您正在做什么。
彩信备份
这是MongoDB备份方法的法拉利 - 它提供实时备份和根据时间点恢复，设置和恢复非常简单...但是，它的价格相当高，在AWS中更是如此，因为数据被发送到（当然是加密的）到MMS，这应该算作外部流量。但是，我仍然建议在 AWS 上使用 MMS：任何与金融交易（在业务意义上）直接相关或具有极其严格的 SLA 的内容都应该使用 MMS，因为它提供了真正的时间点恢复。