In this recipe, we will look at some basic backup and restore operations using utilities such as mongodump and mongorestore to backup and restore files.
We will be starting a single instance of mongod. Refer to the Single node installation of MongoDB recipe in Chapter 1, Installing and Starting the MongoDB Server, to start a Mongo instance and connect to it from a Mongo shell. We will need some data to back up; if you already have some data in your test database that would be fine, else create some from the countries.geo.json file available in the code bundle, using the following command:
$ mongoimport -c countries -d test --drop countries.geo.json
- With the data in the test database, execute the following command, assuming we want to export the data to a local directory called
dumpin the current directory:$ mongodump -o dump -oplog -h localhost -port 27017Verify that there is data in the
dumpdirectory. All files should be.bsonfiles, one per collection, in the respective database folder created. - Now let us import the data back into the MongoDB server using the following command. This is again with an assumption that we have the directory dump in the current directory with the required
.bsonfiles present in it.mongorestore --drop -h localhost -port 27017 dump -oplogReplay
We executed just a couple of steps to export and restore the data. Let us now see exactly what it does and what the command-line options for this utility are. The mongodump utility is used to export the database into .bson files, which can later be used to restore the data in the database. The export utility exports one folder per database, except the local database, and then each of them will have one .bson file per collection. In our case we used the -oplog option to export a part of the oplog as well, and the data will be exported to the oplog.bson file. Similarly, we import the data back into the database using the mongorestore utility. We explicitly ask the existing data to be dropped by providing the --drop option before the import and replay of the contents in the oplog, if any.
The mongodump utility simply queries the collection and exports the contents to the files. The bigger the collection, the more will be the time taken to restore the contents. It is thus advisable to prevent the write operations when the dump is being taken. In case of sharded environments, the balancer should be turned off. If the dump is taken while the system is running, export it with the -oplog option to export the contents of the oplog as well. This oplog can then be used to restore the point-in-time data. The following are some of the important options available for the mongodump and mongorestore utilities, first for mongodump.
Similarly, for the mongorestore utility, the options are as follows. The meaning of the options --help, -h or --host, --port, -u or --username, -p or --password, --authenticationDatabase, -d or --db, -c or –collection is same as in case of mongodump:
One might even think "why not copy the files and take a backup?". That works well, but there are a few problems associated with it. The first being, you cannot get a point-in-time backup unless the write operations are disabled and secondly, the space used for backups is very high, as the copy would also copy the zero-padded files of the database, as against the mongodump utility that exports just the data.
Having said that, filesystem snapshotting is a commonly used practice for backups. One thing to remember is that, while taking the snapshot, the journal files and the data files need to come in the same snapshot for consistency.