Survival guide to Backup & Restore MongoDB | weKnow Inc. Skip to main content

Survival guide to Backup & Restore MongoDB

Despite being on the market for over a decade, to many, MongoDB still carries a mythical tone with a hint of ‘wizardry’.

The popular misconception is that MongoDB is only suitable for hip startups and former startups that are still considered ‘hip’ and out of the box, such as AirBnB.

Even with all the buzz and talk around MongoDB, the adoption rate remains relatively low in comparison with other ‘standard’ relational database technologies. Not many seem to understand that to be successful in the world of code you must approach everything new with an open mind.

Besides bearing an open mind, you need to incorporate an avenue to test and learn new technologies and tools. Personally, I choose to learn how to use new tools by trying to accomplish routine tasks.

In this blog I’ll explain to backup and restore data between different MongoDB environments. A simple yet critical task that we to do all too often.

 

Basic tools for MongoDB backup and restore

First things first, we need to include the CLI tools needed to access and operate our mongo databases. These tools are usually available in the same package that contains the mongo CLI client.

Installation on Mac is a piece of cake using [brew] using the following command.

$ brew install mongodb

If you are looking a more intuitive interface to interact with your Mongo Databases, I recommend using RoboMongo (even though it doesn't include backup features).

 

Connecting to the Database

Local database

As with any regular database, to connect, you need the server, port and database name (when using local setup). If you are connecting to a remote database, you need to provide a username, password, and authentication mode.

For example, to connect to a database named meteor inside your localhost, and running in port 3001, you would use the following command*.

$ mongo 127.0.0.1:3301/meteor

*The client shell version and server versions don’t necessarily have to match. You can also see the warning generated in the image below.

Remote database

As previously mentioned connecting to a remote MongoDB database, requires more information, in this example, I'll use the server Mongo Cloud Atlas.

In addition, to being a None-SQL database, MongoDB is also a distributed database that automatically implements the replication concept, this is an incredibly significant feature. I still have nightmares from the first time I tried to implement that in MySQL.

To connect to the remote server, you need to provide the information of all replicas or nodes, as you can see in the following command.

$ mongo "mongodb://cluster0-shard-00-00-XXX.mongodb.net:27017,cluster0-shard-00-01-XXX.mongodb.net:27017,cluster0-shard-00-02-XXX.mongodb.net:27017/test?replicaSet=Cluster0-shard-0" --authenticationDatabase admin --ssl --username MYSUPERUSER --password MYSUPERPASS

In this case, MongoDB Cloud atlas utilizes different methods of authentication; the default method is using an internal database for users. Also, the method of connection we’ll use is SSL, it’s important to try to keep our information secure.

If everything went as expected, you now have access to a regular command line, and you can execute queries as usual as you do with your local database.

 

Backing up your Mongo database

To backup our database local or remote we’ll use the program mongodump

Local Database

Depending on your connection the order and format may differ a little, but the output folder containing your backup should be the same

$ mongodump --host 127.0.0.1 -d meteor --port 3201 --out ~/Downloads/

After a successful execution, inside the output folder, a new folder with the name of the database will be created, in this example a ‘meteor’ folder.

Inside the folder, you will find two files per collection in database. One file with extension json which will contain your collection’s metadata about the structure and definitions, and another with extension bson, where b stands for binary which is where the data is stored.

Remote Database

mongodump --host cluster0-shard-00-00-XXX.mongodb.net --port 27017 -d MYDATABASE --username MYSUPERUSER --password MYSUPERPASS --authenticationDatabase admin --ssl --out ~/Downloads/

Just as we had done earlier in the connection step, we provide username, password and authentication method, ensuring that we use SSL for our connection.

We also provide the database we want to backup, in this case only one node is required, because in theory all of them are sync.

Restoring your Mongo Database.

To import our backup we will use the program **mongorestore**

Local Database

This command follows the same rules of mongodump, below you could find an example


$ mongorestore --host 127.0.0.1:3201 -d meteor ~/Downloads/meteor/

If we want to import only one specific collection, we just need to include the extra information for the particular collection as you can see below.

$ mongorestore --host 127.0.0.1:3201 -d meteor --collection mycollection ~/Downloads/meteor/mycollection.bson

Remote Database

Here again we need to provide all node replicas, check the following example

$ mongorestore --host "Cluster0-shard-0/cluster0-shard-00-00-XXX.mongodb.net:27017,cluster0-shard-00-01-XXX.mongodb.net:27017,cluster0-shard-00-02-XXX.mongodb.net:27017" -d MYDATABASE -u MYSUPERUSER -p 'MYSUPERPASS' --authenticationDatabase admin --nsExclude 'admin.system.users' --nsExclude 'admin.system.roles' --ssl ~/Downloads/meteor

You can clearly see that the fundamentals are not that far removed from any backup and restore in a SQL based DB. I hope this guide eliminates an excuse that has been holding you back from dipping your toes in MongoDB.

 

Happy NO-SQL queries!

Big or Complex Project,
Not Enough Devs?

We help development teams meet their deadlines by seamlessly integrating our highly skilled developers.