當使用了 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 是為了解決應對不同的風險，在實際生產環境中都需要。