Backup and restore your MongoDB database

This blog post is about backing up and restoring your MongoDB database.
We’ll take a closer look how you can easily download the content of your database to your local machine and restore from it to your remote MongoDB host.

We have to note here that this “backup-Solution” is not a production ready backup system. You should setup replica sets and use a production ready MongoDB setup to backup critical data.

However it’s a good starting point to get your data from the MongoDB database and restore it easily.

Backing up your database

Let’s start with the backup-Process.
We pretend that we have a remote MongoDB-Machine running and want to store a snapshot of our database to our local machine.

MongoDB has a nice handy utility called “mongodump” which we can use to take a snapshot of our database:

mongodump -h our.mongodbhost.com:12345 -d testdb -u testuser -p password -o ~/Desktop<br />

Replace the parameters in this shell-Command so that it points to your MongoDB host and uses your MongoDB credentials.

A backup of our MongoDB will be downloaded to our local machine and stored on the desktop after we’ve run the command. That was very easy!

Restoring a database

Now you have a snapshot of your database. Good!
Let’s say something bad happened at night. Your database was compromised and everything was deleted.
This is bad! Really bad!

But you’ve got a backup on your local machine! Let’s restore our backup to our remote machine so that we’re up and running again.

We can restore our MongoDB backup files (we’ve created with the “mongodump”-Command) with the “mongorestore”-Command

cd into the folder which was created by “mongodump” (it contains all the backup-Files (.json and .bson) of your database) and run this command (Replace the parameters accordingly with the ones of your remote database):

mongorestore --host our.mongohost.com --port 12345 --username testuser --password password --db testdb ./<br />

You’ve successfully restored your backup to the remote database-Server and your Meteor application should be functional again. Profit!

Idea: Copy production data to test-System

You’ll often use different environments (e.g. Production, Staging, Testing) of your Meteor application when dealing with mission critical applications.

You could use e.g. staging after you’ve made some changes to your code and test the new changes on your separated staging-Environment before pushing it to production. Another scenario could be that your customer wants to test the new features on the test-System before they give the green light for the production-Release.
All those encapsulated environments are a great way to deal with those circumstances. In theory. But in the real world way less people use those environments effectively (maybe only you).
The problem here is very often the lack of good testing data on the staging- and testing-System. It’s very hard to generate those test-Data effectively.

Why not copying the real production data to the test-System every night so that tests can be done as if they were performed on the production system?

You could use a combination of “mongodump” and “mongorestore” and a cron-Job to automate this process.
Of course be sure that you protect your customers data when you do that (and be sure that you replace the data in the staging / test system rather than the production system!).

Idea: Automatic backups

A cheap automated backup-Solution would be to save the backup-Command in a shell-Script and run a cron job on a remote server so that your database is always automatically backed up.

Just note that “mongodump” does an incremental backup (it won’t save the whole database every time it’s run but rather saves only the differences between the newest version and the last version).
But you could tinker a little bit around to create a script which creates a folder with a timestamp and then backup into that folder.