OPTIONS

MongoDB Backup Methods

When deploying MongoDB in production, you should have a strategy for capturing and restoring backups in the case of data loss events. There are several ways to back up MongoDB clusters:

Backup by Copying Underlying Data Files

You can create a backup by copying MongoDB’s underlying data files.

If the volume where MongoDB stores data files supports point in time snapshots, you can use these snapshots to create backups of a MongoDB system at an exact moment in time.

File systems snapshots are an operating system volume manager feature, and are not specific to MongoDB. The mechanics of snapshots depend on the underlying storage system. For example, if you use Amazon’s EBS storage system for EC2 supports snapshots. On Linux the LVM manager can create a snapshot.

To get a correct snapshot of a running mongod process, you must have journaling enabled and the journal must reside on the same logical volume as the other MongoDB data files. Without journaling enabled, there is no guarantee that the snapshot will be consistent or valid.

To get a consistent snapshot of a sharded system, you must disable the balancer and capture a snapshot from every shard and a config server at approximately the same moment in time.

If your storage system does not support snapshots, you can copy the files directly using cp, rsync, or a similar tool. Since copying multiple files is not an atomic operation, you must stop all writes to the mongod before copying the files. Otherwise, you will copy the files in an invalid state.

Backups produced by copying the underlying data do not support point in time recovery for replica sets and are difficult to manage for larger sharded clusters. Additionally, these backups are larger because they include the indexes and duplicate underlying storage padding and fragmentation. mongodump, by contrast, creates smaller backups.

For more information, see the Backup and Restore with Filesystem Snapshots and Backup a Sharded Cluster with Filesystem Snapshots for complete instructions on using LVM to create snapshots. Also see Back up and Restore Processes for MongoDB on Amazon EC2.

Backup with mongodump

The mongodump tool reads data from a MongoDB database and creates high fidelity BSON files. The mongorestore tool can populate a MongoDB database with the data from these BSON files. These tools are simple and efficient for backing up small MongoDB deployments, but are not ideal for capturing backups of larger systems.

mongodump and mongorestore can operate against a running mongod process, and can manipulate the underlying data files directly. By default, mongodump does not capture the contents of the local database.

mongodump only captures the documents in the database. The resulting backup is space efficient, but mongorestore or mongod must rebuild the indexes after restoring data.

When connected to a MongoDB instance, mongodump can adversely affect mongod performance. If your data is larger than system memory, the queries will push the working set out of memory.

To mitigate the impact of mongodump on the performance of the replica set, use mongodump to capture backups from a secondary member of a replica set. Alternatively, you can shut down a secondary and use mongodump with the data files directly. If you shut down a secondary to capture data with mongodump ensure that the operation can complete before its oplog becomes too stale to continue replicating.

For replica sets, mongodump also supports a point in time feature with the --oplog option. Applications may continue modifying data while mongodump captures the output. To restore a point in time backup created with --oplog, use mongorestore with the --oplogReplay option.

If applications modify data while mongodump is creating a backup, mongodump will compete for resources with those applications.

See Back Up and Restore with MongoDB Tools, Backup a Small Sharded Cluster with mongodump, and Backup a Sharded Cluster with Database Dumps for more information.

MongoDB Management Service (MMS) Cloud Backup

The MongoDB Management Service supports the backing up and restoring of MongoDB deployments.

MMS continually backs up MongoDB replica sets and sharded clusters by reading the oplog data from your MongoDB deployment.

MMS Backup offers point in time recovery of MongoDB replica sets and a consistent snapshot of sharded clusters.

MMS achieves point in time recovery by storing oplog data so that it can create a restore for any moment in time in the last 24 hours for a particular replica set or sharded cluster. Sharded cluster snapshots are difficult to achieve with other MongoDB backup methods.

To restore a MongoDB deployment from an MMS Backup snapshot, you download a compressed archive of your MongoDB data files and distribute those files before restarting the mongod processes.

To get started with MMS Backup sign up for MMS, and consider the complete documentation of MMS see the MMS Manual.

MongoDB Management Service (MMS) On Prem Backup Software

MongoDB Subscribers can install and run the same core software that powers MongoDB Management Service (MMS) Cloud Backup on their own infrastructure. The On Prem version of MMS, has similar functionality as the cloud version and is available with Standard and Enterprise subscriptions.

For more information about On Prem MMS see the MongoDB subscription page and the MMS On Prem Manual.

Further Reading

Backup and Restore with Filesystem Snapshots
An outline of procedures for creating MongoDB data set backups using system-level file snapshot tool, such as LVM or native storage appliance tools.
Restore a Replica Set from MongoDB Backups
Describes procedure for restoring a replica set from an archived backup such as a mongodump or MMS Backup file.
Back Up and Restore with MongoDB Tools
The procedure for writing the contents of a database to a BSON (i.e. binary) dump file for backing up MongoDB databases.
Backup and Restore Sharded Clusters
Detailed procedures and considerations for backing up sharded clusters and single shards.
Recover Data after an Unexpected Shutdown
Recover data from MongoDB data files that were not properly closed or have an invalid state.