Summary of valid backup approaches (single mongod). This only relates to ways of backing up a single mongod process (ie. consistency of data files). Backing up a distributed system such as a sharded cluster or replica set is a separate topic.
|
WiredTiger |
WiredTiger |
WiredTiger |
MMAPv1 |
MMAPv1 |
| Approach |
3.4 |
3.2 |
3.0 |
with journal |
NO journal[1] |
| Cloud Manager or Ops Manager Backup |
✅ |
✅ |
✅ |
✅ |
✅ |
clean mongod shutdown (then file copy[2] or snapshot) |
✅ |
✅ |
✅ |
✅ |
✅ |
file copy[2] (while under fsyncLock()) |
✅ |
✅ |
🚫 [6] |
✅ |
✅ |
| file copy[2] (plain) |
🚫 |
🚫 |
🚫 |
🚫 |
🚫 |
single[3] atomic snapshot (while under fsyncLock()) |
✅ |
✅ |
✅ |
✅ |
✅ |
| single[3] atomic snapshot (plain) |
✅ [5] |
✅ [5] |
✅ [5] |
✅ |
🚫 |
multiple[3] atomic snapshots (while under fsyncLock()) |
✅ |
✅ |
🚫 [6] |
✅ |
✅ |
| multiple[3] atomic snapshots (plain) |
🚫 |
🚫 |
🚫 |
🚫 |
🚫 |
mongodump --oplog[4] |
✅ |
✅ |
✅ |
✅ |
✅ |
| Key |
|
| ✅ |
Data files will be consistent. Backup can be trusted. |
| 🚫 |
Data files might be inconsistent. Backup cannot be trusted. |
| Notes |
|
| 1 |
Not recommended in normal situations. Listed mainly for completeness |
| 2 |
"File copy" includes any utility or program that reads files non-atomically, eg. cp, scp, rsync, tar, gzip etc |
| 3 |
"single" vs "multiple" refers to the number of snapshots required for the entire dbPath. This includes the contents of the journal directory, and any other directories if directoryPerDB or directoryForIndexes are in use |
| 4 |
And also mongorestore --oplogReplay when restoring. Without this, the backup will be consistent, but might not be point in time. Although mongodump/mongorestore will never cause problems with the consistency of data files in the dbPath, they have other issues that often make them less desirable |
| 5 |
Journalling in WiredTiger is not necessary to ensure data file consistency when using snapshots. However, journalling is still recommended in WiredTiger because it minimises data loss for unexpected shutdowns |
| 6 |
In MongoDB 3.0 with WiredTiger, fsyncLock() only prevents user writes from occurring, and other system threads may modify the data files. This has been addressed since MongoDB v3.2 |