我们需要多长时间在 AWS 上执行 MongoDB 备份？

Question

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

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

Answer 1

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

1. 备份间隔首先取决于最坏情况下可接受的数据丢失情况。
2. AWS（或 MongoDB）提供的确保数据可用性的方法不能替代备份。例如，如果数据因 DBA 错误而丢失，磁盘镜像将无济于事。
3. 备份间隔和方法应反映您的（内部？）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，因为它提供了真正的时间点恢复.