当使用了 Replication 后，可能会产生“我们是否再需要备份”这样的疑问。换而言之， Replication 是否已经充分保护了我们的数据”？
而 Backup 和 Replication 主要的区别在于他们存在的目的不同：Replication 是为了提高应用程序的可用性，而 Backup 则是用于灾难恢复。
可用性是用于衡量应用程序处在可工作状态的时间的比例、能够提供给用户最终访问的能力。随着时间的推移，我们服务器总可能遭受一些可预测的故障，而且这类问题往往没有什么预告。 比如，硬件驱动不可用，诸如电源，网卡和其他个别机器组件之类等。 有时候服务器的磁盘空间不足，需要脱机安装更大的磁盘， 这些问题都会影响到我们硬件设施的可用性，尽管影响的方式有所不同。
诸如上面提到的这些问题最终都会导致你的应用程序不可用。为了孤立隔离这些服务环境基础设施不可避免的事件，需要给我们的应用程序建立冗余。当某一个组件变得不可用时，冗余的备份系统能够直接地、透明地接管该组件的任务。在 MongoDB 中，这种冗余备份机制便被称之为 Replication。
在 MongoDB 的 Replication 中，所有节点成员将会保持同步。所有数据库写操作将会在 Primary 节点进行，并快速同步到 Secondary 节点。当 Primary 节点挂掉以后，将会在剩余的 Secondary 节点中选取出新的 Primary 节点。当然，我们既可以从中 Replica Set 中移除某个节点，也可以无缝添加新的成员节点。
Replica Set 能确保主节点在发生故障的情况下，你的应用程序仍然可用。 故障转移会在几秒钟内自动发生，少数例外情况将不会对最终用户造成影响。 就算是单个机器挂掉或处于维护状态，也不会影响应用程序的可用性。
相比而言，灾难性恢复，讲的是关于一些不可预测的事件，这些事件往往会摧毁我们之前采取的冗余措施。这些事件分为两类： 第一类是人为错误，第二类是灾难性的故障。
人为错误。应用程序 BUG、 黑客的恶意攻击、 意外删除或者主节点数据被损坏。在这些场景中，所有的这些错误通常会在几秒的时间内通过 Primary 节点同步到所有的 Replica Set 成员。人为错误跟磁盘故障一样，仅仅这两条足以说明需要备份的理由。
在灾难性故障中，包含永久删除所有 Replica Set 成员的场景。如果你的所有服务节点（mongod 进程）都在同一个数据库中心（同一台服务器），一场火灾就有可能摧毁所有的服务。甚至，某个对公司不满的即将离职的员工就可以删除所有的数据。
针对这些低概率时间，我们需要一个相对廉价的解决方案来隔离我们的生产系统。在MongoDB 中，这种可防御灾难措施便是备份。
所有的备份系统都共享了操作系统为过去某一刻时间提供 snapshot 的功能特性。快照永远冻结是备份系统的关键特性。执行快照备份的系统应该远离我们的生产环境，在物理上，逻辑上以及管理上都应该远离。快照恢复会将会回滚到引起数据丢失的灾难性事件前的时刻。
总结一下：MongoDB 备份非常的容易，我们期望引起备份恢复的事件永远不要发生（如果经常发生，我们需要认真的重新审视一下我们的方案）。另一方面，Replication 对于相当普遍的事件提供了容错性，并且能够在没有用户意识到事件的情况下进行解决。Backup 和 Replication 是为了解决应对不同的风险，在实际生产环境中都需要。
