我们需要在AWS上执行MongoDB备份的频率是多少？

Question

我开始分析MongoDB在Amazon AWS上的工作方式，我感觉这里缺少基本的东西。根据我在Amazon Storage文档上所读的内容，看起来Amazon会自动对其硬件磁盘进行一些备份。因此，如果他们能够透明地还原每个磁盘（存储MongoDB数据），那么我是否还需要关心备份和恢复？

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

Answer 1

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

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

这是我的方法。简化后，需要进行详细的分析，以了解用例，每小时停机的直接和间接成本以及许多其他因素。

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

所提到的备份方法之间的比较：

mongodump

一个漂亮的工具，它使您可以创建远程计算机的备份，这是一个优势，因为您不必手动从数据承载计算机上移动数据，也不需要在该计算机上配置额外的磁盘空间。缺点是恢复速度很慢。MongoDB建议仅在小型数据库上使用mongodump，我只能第二次使用。至于小的定义，我个人画了一条大约1GB的线。

LVM快照

正确完成后，此方法将非常灵活-您可以在一个步骤中对MongoDB数据和其他应用程序数据（例如文件）进行一致的备份，然后tar从中创建压缩文件并将其存储在异地位置。非常简单的shell脚本的手段。缺点是您需要过度配置磁盘，压缩也需要时间和资源，并且您需要对自己的工作有所了解。

彩信备份

这是用于MongoDB的备份方法的法拉利–它提供实时备份和按时间点恢复，设置和恢复非常简单...但是，它具有相当高的价格，在AWS中更是如此，数据被发送（当然是加密的）到MMS，这应该算作外部流量。但是，在某些情况下，我建议在AWS上使用MMS：与财务交易（在业务意义上）直接相关或具有非常严格的SLA的任何事物都应使用MMS，因为它可以提供实时的时间点恢复。