Backup and Restore MongoDB Databases Using Mongodump and Mongorestore – Part 1
- Backup a Single Collection
We simply can backup a single collection from a database instead all existing collections by adding -c, --collection=<collection-name>
option, this will only backup one collection. In the following two examples, we backup the order_logs collection from elcinema_nosql_staging database
Example 1: Backup a single database’s collection with no authentication used
In case you do not use authentication with your mongoDB server, to backup a single database’s collection, you just need to run following command:
# mongodump -d elcinema_nosql_staging -c order_logs --gzip -o OneCollection
We used a new option -c
to specify the collection name. Here’s the output of the command and the created directory:
2017-02-27T11:34:28.386+0200 writing elcinema_nosql_staging.order_logs to
2017-02-27T11:34:30.930+0200 [........................] elcinema_nosql_staging.order_logs 134774/5394411 (2.5%)
.....
2017-02-27T11:36:48.930+0200 [#######################.] elcinema_nosql_staging.order_logs 5304220/5394411 (98.3%)
2017-02-27T11:36:51.228+0200 [########################] elcinema_nosql_staging.order_logs 5394411/5394411 (100.0%)
2017-02-27T11:36:51.228+0200 done dumping elcinema_nosql_staging.order_logs (5394411 documents)
As you see, it performs the backup on only one collection “order_logs” from the database ” elcinema_nosql_staging“, let’s check on the created directories and their sizes:
# ls OneCollection/
elcinema_nosql_staging
# ls OneCollection/elcinema_nosql_staging/
order_logs.bson.gz order_logs.metadata.json.gz
# du -sh OneCollection/elcinema_nosql_staging/
312M OneCollection/elcinema_nosql_staging/
Yes, it backed up one compressed collection.
Example 2: Backup a single database’s collection with authentication used
In case you use authentication with your mongoDB server, you must use --authenticationDatabase=<database-name>
option along with the username
and password
options otherwise you will face an error.
To backup a single database’s collection with authentication enabled on the MongoDB instance, you just need to run following command:
# mongodump -u<Your_User> -p<Your_Password> --authenticationDatabase=admin -d elcinema_nosql_staging -c order_logs --gzip -o OneCollection
We used a new option --authenticationDatabase=<database-name>
to specify the authentication database name. Output and checks of this command is same as the above command:
Hints:
1. For a single collection backup with authentication, you must use --authenticationDatabase=<database-name>
otherwise the following error will appear:
Failed: error connecting to db server: server returned error on SASL authentication step: Authentication failed.
This is the end of this part, next part will deal with databases restore.
Part 2: Performing a MongoDB Database Restore.
Once you’ve taken the backup of a MongoDB database using mongodump
, you can restore it using mongorestore
command. In case of an disaster where you lost your mongoDB database, you can use this command to restore the database. Or, you can just use this command to restore the database on a different server for testing purpose.
Depending on different options you used when performing the backup, there are some options you must use to restore your backup. We’ll use mongorestore
command to restore the three type of backups we created in the previous part. We’ll perform a hot restore “With MongoDB instance is running”, Just stop the MongoDB instance before running the following examples to perform a cold restore.
Before we start with performing our restore process, we need to see the syntax and options of mongorestore
command:
Mongorestore Syntax and Options
Here’s the basic syntax and options of the mongorestore
command:
Usage:
$ mongorestore <options> <directory or file to restore>
Very simple usage, it restore backups generated with mongodump to a running server.
Options:
The following table lists the most used options, which used through this post.
Option | Usage |
-h, --host=<hostname> |
mongodb host to connect to (setname/host1,host2 for replica sets) |
--port=<port> |
server port (can also use –host hostname:port) |
-u, --username=<username> |
username for authentication |
-p, --password=<password> |
password for authentication |
--authenticationDatabase=<database-name> |
database that holds the user’s credentials |
-d, --db=<database-name> |
database to use when restoring from a BSON file |
-c, --collection=<collection-name> |
collection to use when restoring from a BSON file |
--drop |
drop each collection before import |
--gzip |
decompress gzipped input |
--oplogReplay |
replay oplog for point-in-time restore |
These are the most common options we’ll use to restore our backups. Let’s continue to our examples. Option --drop
is used with all the following examples “Must”
- Restore All Databases
To restore all the databases backed up in the Backup examples, use any of the following commands:
1. For Non-compressed backups, and the MongoDB not using authentication
# mongorestore --drop Semari/
2. For Non-compressed backups, and the MongoDB is using authentication
# mongorestore -u<Your_User> -p<Your_Password> --authenticationDatabase=admin --drop Semari/
3. For a compressed backups, and the MongoDB not using authentication
# mongorestore --drop --gzip Semari/
4. For a compressed backups, and the MongoDB is using authentication
# mongorestore -u<Your_User> -p<Your_Password> --authenticationDatabase=admin --gzip --drop Semari/
Here’s a sample output for the above command:
2017-02-27T13:23:11.913+0200 preparing collections to restore from
2017-02-27T13:23:12.008+0200 reading metadata for elcinema_nosql_staging.order_logs from Semari/elcinema_nosql_staging/order_logs.metadata.json.gz
2017-02-27T13:23:12.174+0200 restoring elcinema_nosql_staging.order_logs from Semari/elcinema_nosql_staging/order_logs.bson.gz
2017-02-27T13:23:14.901+0200 [........................] elcinema_nosql_staging.order_logs 8.37MB/311MB (2.7%)
....
2017-02-27T13:24:32.901+0200 [#######################.] elcinema_nosql_staging.order_logs 309MB/311MB (99.3%)
2017-02-27T13:24:33.380+0200 [########################] elcinema_nosql_staging.order_logs 311MB/311MB (100.0%)
2017-02-27T13:24:33.380+0200 no indexes to restore
2017-02-27T13:24:33.380+0200 finished restoring elcinema_nosql_staging.order_logs (5394411 documents)
2017-02-27T13:24:33.380+0200 restoring users from Semari/admin/system.users.bson.gz
2017-02-27T13:24:33.607+0200 done
- Restore a Single Database
To restore a single database simply, we add -d, --db=<database-name>
option to the above examples, and only use the database backup directory, here’s an example for restoring a compressed single database into a MongoDB instance that using authentication:
# mongorestore -u<Your_User> -p<Your_Password> --authenticationDatabase=admin --db elcinema_nosql_staging --gzip --drop Semari/elcinema_nosql_staging/
Here’s the output of the above command:
2017-02-27T13:34:14.604+0200 the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead
2017-02-27T13:34:14.604+0200 building a list of collections to restore from Semari/elcinema_nosql_staging dir
2017-02-27T13:34:14.777+0200 reading metadata for elcinema_nosql_staging.order_logs from Semari/elcinema_nosql_staging/order_logs.metadata.json.gz
2017-02-27T13:34:14.910+0200 restoring elcinema_nosql_staging.order_logs from Semari/elcinema_nosql_staging/order_logs.bson.gz
2017-02-27T13:34:17.592+0200 [........................] elcinema_nosql_staging.order_logs 9.14MB/311MB (2.9%)
2017-02-27T13:34:20.592+0200 [#.......................] elcinema_nosql_staging.order_logs 19.8MB/311MB (6.4%)
2017-02-27T13:34:23.592+0200 [##......................] elcinema_nosql_staging.order_logs 31.6MB/311MB (10.1%)
....
2017-02-27T13:35:35.592+0200 [#######################.] elcinema_nosql_staging.order_logs 303MB/311MB (97.4%)
2017-02-27T13:35:37.471+0200 [########################] elcinema_nosql_staging.order_logs 311MB/311MB (100.0%)
2017-02-27T13:35:37.471+0200 no indexes to restore
2017-02-27T13:35:37.471+0200 finished restoring elcinema_nosql_staging.order_logs (5394411 documents)
2017-02-27T13:35:37.471+0200 done
- Restore a Single Collection
To restore a single collection from a database simply, along with -d, --db=<database-name>
option, we add -c, --collection=<collection-name>
option to specify the collection name to the above example, and only use the collection backup bson file, here’s an example for restoring a compressed single collection into a MongoDB instance that using authentication:
# mongorestore -u<Your_User> -p<Your_Password> --authenticationDatabase=admin --db elcinema_nosql_staging --gzip --drop --collection order_logs Semari/elcinema_nosql_staging/order_logs.bson.gz
Here’s the output of the above command:
elcinema_nosql_staging/order_logs.bson.gz
2017-02-27T13:46:58.826+0200 checking for collection data in Semari/elcinema_nosql_staging/order_logs.bson.gz
2017-02-27T13:46:58.828+0200 reading metadata for elcinema_nosql_staging.order_logs from Semari/elcinema_nosql_staging/order_logs.metadata.json.gz
2017-02-27T13:46:59.357+0200 restoring elcinema_nosql_staging.order_logs from Semari/elcinema_nosql_staging/order_logs.bson.gz
2017-02-27T13:47:01.811+0200 [........................] elcinema_nosql_staging.order_logs 10.5MB/311MB (3.4%)
2017-02-27T13:47:04.811+0200 [#.......................] elcinema_nosql_staging.order_logs 25.3MB/311MB (8.1%)
.....
2017-02-27T13:48:25.811+0200 [#######################.] elcinema_nosql_staging.order_logs 303MB/311MB (97.2%)
2017-02-27T13:48:27.948+0200 [########################] elcinema_nosql_staging.order_logs 311MB/311MB (100.0%)
2017-02-27T13:48:27.948+0200 no indexes to restore
2017-02-27T13:48:27.948+0200 finished restoring elcinema_nosql_staging.order_logs (5394411 documents)
2017-02-27T13:48:27.948+0200 done
Hints: 1. Option--drop
must be used withmongorestore
command as it drop collection first before restoring it from the backup. 2. If you neglect--drop
option in any of the above restore examples, you'll face the following error for every document in your collection: - E11000 duplicate key error collection: 3. For MongoDB instance running with authentication, the authenticated user must has the required privilege needed for dropping the collection with option--drop
, otherwise you'll face the following error: Failed: error getting auth version of server: not authorized on admin to execute command { getParameter: 1, authSchemaVersion: 1 }
Finally, I hope this article is helpful for you AND SUPPORT US
If You Appreciate What We Do Here On Mimastech, You Should Consider:
- Stay Connected to: Facebook | Twitter | Google+
- Support us via PayPal Donation
- Subscribe to our email newsletters.
- Tell other sysadmins / friends about Us - Share and Like our posts and services
We are thankful for your never ending support.