Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Restore a MongoDB Logical Backup

DZone's Guide to

Restore a MongoDB Logical Backup

In this tutorial, you will learn how to restore a MongoDB logical backup performed via mongodump to a mongod instance.

· Database Zone ·
Free Resource

Download the Altoros NoSQL Performance Benchmark 2018. Compare top NoSQL solutions – Couchbase Server v5.5, MongoDB v3.6, and DataStax Enterprise v6 (Cassandra).

MongoDB logical backup requires the use of the mongorestore tool to perform the restore backup. This article focuses on this tool and process.

Note: Percona develops a backup tool named Percona-Lab/mongodb-consistent-backup, which is a wrapper for mongodump, adding cluster-wide backup consistency. The backups created by mongodb_consistent_backup (in Dump/Mongodump mode) can be restored using the exact same steps as a regular mongodump backup — no special steps!

-host/-port (and -user/-password)

Required, even if you're using the default host/port (localhost:27017). If authorization is enabled, add -user/-password flags also.

-drop

This is almost always required. This causes mongodump to drop the collection that is being restored before restoring it. Without this flag, the documents from the backup are inserted one at a time and if they already exist the restore fails.

-oplogReplay

This is almost always required. Replays the oplog that was dumped by mongodump. It is best to include this flag on replset-based backups unless there is a specific reason not to. You can tell if the backup was from a replset by looking for the file oplog.bson at the base of the dump directory.

-dir

Required. The path to the mongodump data.

-gzip

Optional. For mongodump >= 3.2, enables inline compression on the restore. This is required if mongodump used the -gzip flag (look for *.bson.gz files if you're not sure if the collection files have no .gz suffix, don't use -gzip).

-numParallelCollections=<number>

Optional. For mongodump >= 3.2 only, sets the number of collections to insert in parallel. By default, four threads are used, and if you have a large server and you want to restore faster (more resource usage, though), you could increase this number. Note that each thread uncompresses bson if the -gzip flag is used, so consider this when raising this number.

Steps

(Optional) If the backup is archived (mongodb_consistent_backup defaults to creating tar archives), un-archive the backup so that ‘mongorestore‘ can access the .bson/.bson.gz files:

$ tar -C /opt/mongodb/backup/testbackup/20160809_1306 -xvf /opt/mongodb/backup/testbackup/20160809_1306/test1.tar
test1/
test1/dump/
test1/dump/wikipedia/
test1/dump/wikipedia/pages.metadata.json.gz
test1/dump/wikipedia/pages.bson.gz
test1/dump/oplog.bson

This command un-tars the backup to ‘/opt/mongodb/backup/testbackup/20160809_1306/test1/dump’.

Check (and then check again!) that you're restoring the right back-up to the right host. When in doubt, it is safer to ask the customer or others.

The Percona mongodb_consistent_backup tool names backup subdirectories by replica set name, so you can ensure you're restoring the right backup by checking the replica set name of the node you're restoring to if it exists.

If you're restoring to a replica set, you will need to restore to the PRIMARY member and there needs to be a majority (so writes are accepted — some exceptions if you override write-concern, but not advised).

Use mongorestore to restore the data by dropping/restoring each collection (-drop flag) and replay the oplog changes (-oplogReplay flag), specifying the restore dir explicitly (-dir flag) to the mongorestore command. In this example I also used authorization (-user/-password flags) and un-compression (-gzip flag):

$ mongorestore --drop --host localhost --port 27017 --user secret --password secret --oplogReplay --gzip --dir /opt/mongodb/backup/testbackup/20160809_1306/test1/dump
2016-08-09T14:23:04.057+0200    building a list of dbs and collections to restore from /opt/mongodb/backup/testbackup/20160809_1306/test1/dump dir
2016-08-09T14:23:04.065+0200    reading metadata for wikipedia.pages from /opt/mongodb/backup/testbackup/20160809_1306/test1/dump/wikipedia/pages.metadata.json.gz
2016-08-09T14:23:04.067+0200    restoring wikipedia.pages from /opt/mongodb/backup/testbackup/20160809_1306/test1/dump/wikipedia/pages.bson.gz
2016-08-09T14:23:07.058+0200    [#######.................]  wikipedia.pages  63.9 MB/199.0 MB  (32.1%)
2016-08-09T14:23:10.058+0200    [###############.........]  wikipedia.pages  127.7 MB/199.0 MB  (64.1%)
2016-08-09T14:23:13.060+0200    [###################.....]  wikipedia.pages  160.4 MB/199.0 MB  (80.6%)
2016-08-09T14:23:16.059+0200    [#######################.]  wikipedia.pages  191.5 MB/199.0 MB  (96.2%)
2016-08-09T14:23:19.071+0200    [########################]  wikipedia.pages  223.5 MB/199.0 MB  (112.3%)
2016-08-09T14:23:22.062+0200    [########################]  wikipedia.pages  255.6 MB/199.0 MB  (128.4%)
2016-08-09T14:23:25.067+0200    [########################]  wikipedia.pages  271.4 MB/199.0 MB  (136.4%)
...
...
2016-08-09T14:24:19.058+0200    [########################]  wikipedia.pages  526.9 MB/199.0 MB  (264.7%)
2016-08-09T14:24:22.058+0200    [########################]  wikipedia.pages  558.9 MB/199.0 MB  (280.8%)
2016-08-09T14:24:23.521+0200    [########################]  wikipedia.pages  560.6 MB/199.0 MB  (281.6%)
2016-08-09T14:24:23.522+0200    restoring indexes for collection wikipedia.pages from metadata
2016-08-09T14:24:23.528+0200    finished restoring wikipedia.pages (32725 documents)
2016-08-09T14:24:23.528+0200    replaying oplog
2016-08-09T14:24:23.597+0200    done

If you encounter problems with mongorestore, carefully read the error message or rerun with several -v flags, e.g.: -vvv. Once you have an error, attempt to troubleshoot the cause.

Check to see that you saw replaying oplog and done after the restore (last two lines in the example). If you don't see this, there is a problem.

As you notice, using this tool for MongoDB logical backup is very simple. However, when using sharding, please note that -oplog is not available and the mongodump uses the primaries for each shard. As this is not advised typically in production, you might consider looking at Percona-Lab/mongodb-consistent-backup to ensure you are consistent and hitting secondary nodes, like mongodump with replica sets, will work.

Download the whitepaper, Moving From Relational to NoSQL: How to Get Started. We’ll take you step by step through your first NoSQL project.

Topics:
database ,tutorial ,mongodb ,database backup ,restore

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}