Back Up and Restore with MongoDB Tools
On this page
This tutorial describes the process for creating backups and restoring data using the utilities provided with MongoDB. The mongodump and mongorestore utilities work with BSON data dumps, and are useful for creating backups of small deployments. For resilient and non-disruptive backups, use a file system or block-level disk snapshot function, such as the methods described in the MongoDB Backup Methods document.
Because mongodump and mongorestore operate by interacting with a running mongod instance, they can impact the performance of your running database. Not only do the tools create traffic for a running database instance, they also force the database to read all data through memory. When MongoDB reads infrequently used data, it can evict more frequently accessed data, causing a deterioration in performance for the database’s regular workload.
When backing up your data with MongoDB’s tools, consider the following guidelines:
Label files so that you can identify the contents of the backup as well as the point in time that the backup reflects.
Ensure that your backups are usable by restoring them to a test MongoDB deployment.
The mongorestore and mongodump utilities work with BSON data dumps, and are useful for creating backups of small deployments. For resilient and non-disruptive backups, use a file system or block-level disk snapshot function, such as the methods described in the MongoDB Backup Methods document.
mongodump excludes the content of the
local database in its output.
To run mongodump against a MongoDB deployment that has access control enabled, you must have privileges that grant find action for each database to back up. The built-in backup role provides the required privileges to perform backup of any and all databases.
Changed in version 3.2.1: The backup role provides additional privileges to back up the system.profile collections that exist when running with database profiling. Previously, users required an additional
read access on this collection.
The utility can create a backup for an entire server, database or collection, or can use a query to backup just part of a collection.
When you run mongodump without any arguments, the command connects to the MongoDB instance on the local system (e.g.
localhost ) on port
27017 and creates a database backup named
dump/ in the current directory.
mongodump --host mongodb.example.net --port 27017
mongodump will write BSON files that hold a copy of data accessible via the mongod listening on port
27017 of the
mongodb.example.net host. See Create Backups from Non-Local mongod Instances for more information.
To specify a different output directory, you can use the --out or -o option:
mongodump --out /data/backup/
mongodump --collection myCollection --db test
This operation creates a dump of the collection named
myCollection from the database
test in a
dump/ subdirectory of the current working directory.
mongodump overwrites output files if they exist in the backup data folder. Before running the mongodump command multiple times, either ensure that you no longer need the files in the output folder (the default is the
dump/ folder) or rename the folders or files.
Use the --oplog option with mongodump to collect the oplog entries to build a point-in-time snapshot of a database within a replica set. With --oplog, mongodump copies all the data from the source database as well as all of the oplog entries from the beginning to the end of the backup procedure. This operation, in conjunction with mongorestore --oplogReplay, allows you to restore a backup that reflects the specific moment in time that corresponds to when mongodump completed creating the dump file.
mongodump --host mongodb1.example.net --port 3017 --username user --password "pass" --out /opt/backup/mongodump-2013-10-24
On any mongodump command you may, as above, specify username and password credentials to specify database authentication.
To restore data to a MongoDB deployment that has access control enabled, the restore role provides the necessary privileges to restore data from backups if the data does not include system.profile collection data and you run mongorestore without the --oplogReplay option.
|If the backup data includes system.profile collection data and the target database does not contain the system.profile collection, mongorestore attempts to create the collection even though the program does not actually restore |
Both the built-in roles dbAdmin and dbAdminAnyDatabase provide the additional privileges.
|To run with --oplogReplay, create a user-defined role that has anyAction on anyResource.|
Grant only to users who must run mongorestore with --oplogReplay.
mongorestore can restore either an entire database backup or a subset of the backup.
New in version 3.6:
All MongoDB collections have UUIDs by default. When MongoDB restores collections, the restored collections retain their original UUIDs. When restoring a collection where no UUID was present, MongoDB generates a UUID for the restored collection.
For more information on collection UUIDs, see Collections.
mongorestore --port <port number> <path to the backup>
Consider the following example:
You may also consider using the mongorestore --objcheck option to check the integrity of objects while inserting them into the database, or you may consider the mongorestore --drop option to drop each collection from the database before restoring from backups.
By default, mongorestore connects to a MongoDB instance running on the localhost interface (e.g.
127.0.0.1 ) and on the default port (
27017 ). If you want to restore to a different host or port, use the --host and --port options.
Consider the following example:
mongorestore --host mongodb1.example.net --port 3017 --username user --password 'pass' /opt/backup/mongodump-2013-10-24
As above, you may specify username and password connections if your mongod requires authentication.