MongoDB备份基本注意事项

数据库系统有责任在操作中随时需要时存储并确保相关数据的一致性。由于数据库故障，人为错误或灾难性故障（可能会完全破坏生产中的操作节点）而导致数据丢失后，大多数公司无法继续开展业务。如果将数据库保留在同一数据中心中，则在遭受严重破坏的情况下，丢失所有数据的风险很高。

复制和备份是确保数据高可用性的常用方法。两者之间的选择取决于数据更改的频率。如果数据不更频繁地更改并且不期望拥有如此多的备份文件，则最好选择备份。另一方面，对于频繁更改的数据，除了通过减少请求的等待时间在特定位置提供数据（例如在特定位置提供数据）相关的其他其他优点外，复制是首选方法。但是，在任何故障情况下，还原期间都可以使用复制和备份来实现最大的数据完整性和一致性。
数据库备份除了提供还原点外，还提供更多优势，这些还原点提供了为开发，开放访问和登台创建新环境的基础，而又不影响生产。开发团队可以快速，轻松地测试新集成的功能并加速其开发。只要结果数据不一致，也可以将备份用于代码错误检查点。

备份MongoDB的注意事项

在某些点创建备份以反映（充当数据库的快照）在给定时刻数据库承载的数据。如果数据库在给定点出现故障，我们可以使用最后一个备份文件将数据库回滚到发生故障之前的某个点。但是，在进行恢复之前，需要考虑一些因素，其中包括：
**恢复点目标
恢复时间目标
数据库和快照隔离
分片的并发症
恢复过程
性能因素和可用存储
灵活性
部署的复杂性**

恢复点目标

这样做是为了确定您准备在备份和还原过程中丢失多少数据。例如，如果我们有用户数据和点击流数据，则用户数据将比点击流分析具有更高的优先级，因为点击流分析可以在还原后通过监视应用程序中的操作来重新生成。对于诸如银行信息，生产行业数据和通信系统信息之类的关键数据，应首选连续备份，并且应间隔很短的时间进行备份。如果数据不经常更改，则如果您执行了例如6个月或1年前的恢复快照，则丢失大量数据的成本可能会更低。

恢复时间目标

这是为了分析和确定还原操作可以完成的速度。在恢复过程中，您的应用程序将导致一些停机时间，该停机时间也与需要恢复的数据量成正比。如果要还原大量数据，则将需要更长的时间。

数据库和快照隔离

隔离度是从逻辑配置和物理角度衡量与主数据库服务器的备份快照有多近的一种度量。如果它们恰好足够近，则恢复时间会缩短，但代价是在销毁数据库的同时被销毁的可能性增加。建议不要将备份和生产环境托管在同一系统中，以避免服务器上的任何干扰也减轻到备份中。

分片的难题

对于通过分片的分布式数据库系统，存在一些备份复杂性，并且可能必须在整个系统上暂停写活动。不同的分片将在不同的时间完成不同类型的备份。考虑到逻辑备份和快照备份，

逻辑备份

• 碎片的大小不同，因此将在不同的时间完成
• 基于MongoDB的转储将忽略–oplog，因此在每个分片上都不会保持一致。

• 可能由于某些碎片可能尚未完成恢复过程而导致平衡器处于关闭状态，所以它可能处于关闭状态

  快照备份

  对于3.2版及更高版本中的单个副本，效果很好。因此，您应该考虑更新您的MongoDB版本。
  恢复过程
  有些人执行备份时没有测试它们是否可以在还原的情况下工作。备份本质上是提供恢复功能，否则将变得无用。您应该始终尝试在其他测试服务器上运行备份，以查看备份是否正常运行。

  性能因素和可用存储

  由于来自数据库本身的数据，备份也倾向于采用多种大小，并且需要进行足够压缩以免占用大量不必要的空间，这些空间可能会削减系统的整体存储资源。可以将它们归档为zip文件，从而减小其整体大小。此外，如前所述，可以从数据库本身将备份归档在不同的数据中心中。
  备份可能会决定数据库的不同性能，因为某些性能可能会使数据库性能下降。在这种情况下，连续备份会带来一些挫折，因此应将其转换为计划的备份，以免维护窗口耗尽。在大多数情况下，将部署辅助服务器以支持备份。在这种情况下：

• 不能一致地备份单个节点，因为在使用mongodump命令时，MongoDB在没有操作日志的情况下使用了未提交读操作，因此在这种情况下备份将不安全。
• 使用辅助节点进行备份，因为该过程本身会根据涉及的数据量花费时间，并且连接的应用程序会导致一些停机时间。如果您使用的主要数据库还必须更新Oplog，则在该停机期间您可能会丢失一些数据

• 还原过程需要很多时间，但是分配的存储资源很小。

  灵活性

  很多时候，您可能不希望在备份过程中获得某些数据，例如以恢复点目标为例，人们可能希望完成恢复并过滤掉用户单击的数据。为此，您需要一个部分备份策略，该策略将提供灵活性，以过滤出您不需要的数据，从而减少恢复时间并减少浪费的资源。增量备份也很有用，这样，只有已更改的数据部分才会从上一个快照备份，而不是为每个快照进行完整备份。

  部署的复杂性

  您的备份策略应易于设置和维护。您还可以计划备份，这样就无需在需要时手动进行备份。

  结论

  如果只有建立适当的备份系统，数据库系统才能保证“生而死”。数据库可能被灾难性因素，人为错误或安全攻击所破坏，这些灾难可能导致数据丢失或损坏。在进行备份之前，必须考虑数据的大小和重要性。始终不建议将备份与数据库放在同一数据中心，以减少备份被同时破坏的可能性。备份可能会改变数据库的性能，因此应注意使用的策略以及何时执行备份。不要在主节点上执行备份，因为这可能会导致备份期间系统停机并因此丢失重要数据