如何備份大型 MongoDB 數據庫
在 MongoDB 中備份大型數據集的推薦方法是什麼？假設我們有大約 10TB 的數據大小 - 您將如何備份它？
我們正在考慮一個隱藏的、可能延遲的副本集節點。延遲將保護我們免受整個數據庫的意外失去。這是一個可行的解決方案嗎？您建議調查哪些其他選項？
謝謝！
由於需要備份 10TB，這變得有點複雜。
副本不能替代正確的備份
雖然延遲的副本集成員可以提供一種相對簡單的方法來幫助您處理意外操作，但正確的備份無法替代，就像 RAID 不能替代基於文件系統的備份一樣。
建議
這在很大程度上取決於您的設置如何。
SAN 快照
對於 10TB，我假設您連接了某種 SAN。在這些環境中備份 MongoDB 的最簡單方法是確保您在文件系統和 MongoDB 上都啟動了日誌，並簡單地對其中一個輔助設備的 SAN 捲進行快照，可能是一個隱藏的捲以確保您的操作不會不要被打擾。這通常只需要幾秒鐘，但請_確保_您的複制 oplog 視窗足夠。否則，您可能需要重新同步輔助節點。
不要使用 mongodump
我不得不不同意 RolandoMySQLDBA 關於 mongodump 的使用。首先，它在伺服器上施加了鎖。儘管它們的解除速度相對較快，但絕對數量的鎖可能會累加並干擾您的操作，除非在隱藏節點上執行或當沒有讀取首選項命中輔助節點時。另外，它並不是很快。我希望它至少可以執行幾個小時，很可能需要比您的備份視窗更長的時間。旁注：始終使用該選項執行 mongodump
--oplog. 還要記住，mongodump 不備份索引，而是創建索引的操作。這些索引必須在還原期間重新創建，這可能會大大增加您所需的時間。根據我的經驗，如果您必須恢復數據庫，您希望盡快恢復。mongodump 不適合備份 10TB 的另一點。LVM 快照注意事項
*只要您在 mongod 中啟用了日誌功能，*就可以在正在執行的 mongod 實例上創建 LVM 快照（根據我的經驗，在 FS 級別啟用它也沒有什麼壞處）。但是，LVM 快照會帶來一些影響。首先，您顯然需要有足夠的磁碟空間來在備份操作期間進行更改。讓我澄清一下。
假設您的每小時更改率為 500GB。並且您希望在將備份上傳到某個儲存之前對其進行備份。即使使用並行 bzip2，10TB 的壓縮也需要幾個小時才能完成，因為很可能您的海量儲存吞吐量將成為您的限制因素。假設將數據壓縮到 2TB 需要 2 個小時。所以現在我們總共需要 2TB + 2500GB 的可用磁碟空間，LVM 快照需要 1TB。這將至少需要過度配置您的文件系統*30%。如果您想擁有適當的安全裕度，這可以輕鬆增加到 60-70%（原始文件系統的使用率為 0.8 時為 20%，快照大小加上 bzip 壓縮備份本身所需的空間相同）。在大多數生產環境中，這是不可接受的，因為過度配置將是靜態的（您不希望備份腳本動態地破壞您的 LVM，對嗎？）。
彩信備份
雖然 MMS 備份有一些很棒的功能（連續備份、簡單的時間點恢復），但它也有一些嚴重的缺點：大型部署的價格標籤很容易達到數千。假設這 10TB 的每小時更改率為 500GB，對於雲備份來說，這將是一個中等的六位數總和。每月。
我的建議是，他會為您的伺服器進行企業訂閱，以便有資格擁有本地 MMS 實例，包括備份。
概括
以下是我會按偏好降序排列的選項。
- SAN 快照：易於實施，相對便宜
- 企業訂閱：最佳功能。安裝它，配置它，忘記它，當你需要它時它就在那裡
- LVM 快照：易於實施，但必要的過度配置成本可能會隨著時間的推移而累積。