应用错误收集

不幸的是，您的假设很糟糕 - MongoDB是分析数据的权威来源，而不是报告数据库。报告数据库仅包含生成报告所需的聚合信息（主要是）。事实上，如果SQL DB出现问题，那么它的想法是从源MongoDB重建它。请记住：在您添加两个号码后，您无法添加两个号码！

备份与复制 备份是数据库的时间点视图，其中复制是当前数据库的多个活动副本。我主张通过这种类型的数据进行备份复制。为什么？很高兴你问！

货币 - 在什么情况下你想要恢复50GB的MongoDB？如果它是一周大了怎么办？如果是一个月怎么办？真正唯一有用的数据是当前数据，网站是易变的地方 - 日志数据备份在一小时内就过时了。如果您对陈旧数据进行个性化设置是为了提供良好的用户体验？
成本 - 备份大型数据集在时间，存储容量和计算要求方面成本高昂;他们也是一种恢复的痛苦，他们越大就越有可能在某处腐败

开展业务

在生产MongoDB环境中，确实应该有2-3个副本。如果其中一个盒子死了，他们有时会这样做，那就是拯救你的屁股--MongoDB非常努力地处理磁盘。

这些副本是自我修复的，并且总是最新的（非常多）因此它们比备份要好得多。您一次失去所有副本的可能性非常低，除了一个特殊的边缘情况......升级。因此，备份实际上只能防止硬件故障或数据损坏，这在多实例副本集中已经得到了非常有效的处理。除非你是偏执狂，否则你永远不会使用那个备份，并且它会花费你很多钱。

Sitecore升级

这是杀手级边缘案例 - 在运行升级之前始终进行备份（请参阅Back Up and Restore with MongoDB Tools），因为您可以在一个动作中损坏所有副本，并且您希望能够回滚

数据修整（旁注）

你没有问过这个问题，但是在某些时候你会想到＆＃34;我怎么能每天备份这个170GB的怪物数据库呢？这太荒谬了＃34; - 而且你是对的。

关于这些数据应该持续多长时间，有各种各样的思想流派 - 只有您或您的客户才能回答这个问题。我建议保留它直到那里太多，然后决定你必须摆脱多少。尽可能多地保持。