mongodb - 我们需要多久在 AWS 上执行一次 MongoDB 备份？

Question

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

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

Answer 1

我认为你的分析是基于错误的，甚至是危险的假设。一些基础知识:

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

这是我的做法。很简单，因为详分割析需要了解用例、每小时停机的直接和间接成本以及相当多的其他因素。

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

上述备份方法之间的小比较:

mongodump

一个漂亮的工具，它允许您创建远程计算机的备份，这是一个优点，因为您不必手动从数据承载计算机中移动数据，也不需要提供额外的磁盘空间在那台机器上。它的缺点是恢复速度相当慢。 MongoDB 建议仅在小型数据库上使用 mongodump，我只能其次。至于小的定义，我个人以1GB左右为界线。

LVM 快照

如果操作正确，此方法非常灵活 - 您可以对 MongoDB 数据和其他应用程序数据(例如文件)进行一致的备份，例如，只需一步即可创建压缩的 tar 文件并通过非常简单的 shell 脚本将其存储在异地位置。缺点是您需要过度配置磁盘，压缩也需要时间和资源，并且您需要对您正在做的事情有一些了解。

彩信备份

这是 MongoDB 备份方法中的法拉利 - 它提供实时备份和根据时间点恢复，设置和恢复非常简单...但是，它的价格相当高，更是如此在 AWS 中，当数据发送(当然是加密的)到 MMS 时，这应该算作外部流量。然而，在某些用例中，我仍然建议在 AWS 上使用 MMS:任何与金融交易直接相关(在业务意义上)或具有极其严格 SLA 的内容都应该使用 MMS，因为它提供真正的时间点恢复.