To do a proper backup of MongoDB requries you shutdown the server instance, run a backup then turn the server back on. This might be just fine for some use cases but more then likely you don’t want to have to turn off your server (if only to keep your uptime: 3790344373243 seconds in your mongodb stats.)

Why Do You Need to Shutdown?

Trying to make a copy of your MongoDB files for a backup while the server is running will often result in corrupted files.

In MongoDB 1.3.1 (and up) you can use the fsync and lock command (which flushes writes, locks the database then backs up the datafiles.) However this still requires you to lock you database for writing for an unknown period of time.

Backup: Now Without Backup!

We can get around all these issues however with two different options: mongodump or slave backups.

mongodump

This method works much like mysqldump, it simply takes all the data for a certain collection or your entire database of collections and outputs it into text files.

A copy of mongodump comes with the download of MongoDB and runs like so (assuming you are on the localhost):

$ ./mongodump

If you dumping a external host (like dump.tuck.com) just add …

$ ./mongodump --host dump.truck.com

The datafiles will be dumped to a directory call dump in your current directory.

To back up just one collection:

$ ./mongodump --db meals --collection dinners

You can then use mongorestore to restore you database from backup. You can run a dump while the database is running without fear of any corruption.

Important Note: The official MongoDB DOCs give this warning about mongorestore:

These tool just work with the raw data (the documents in the collection); they do not save, or load, the metadata like the defined indexes or (capped) collection properties. You will need to (re)create those yourself in a separate step, before loading that data.

Of course, if you don’t use custom indexes and such you won’t run into a problem.

Slave Backup

Another option is to use what is called “slave backups” … basically you setup a slave MongoDB server, then use that to do your backups (shut it down, backup, start it again) … never touching your production server at all.

A MongoDB server in slave mode will constantly poll your master server to get the latest copy of each collection and create a duplicate on your slave.

This also means you have a copy (or twin) of your production database always ready to go in the unfortunate event that your production server goes down.

Start Me Up

To create a slave all you need to do is download MongoDB to another machine and install it or even run MongoDB twice on differant ports on the same machine!

You can use this to keep an up-to-date “backup” always ready for you without needing to run any scheduled backups or taking down you server.

$ ./mongod --slave --source mongo.example.com

Or, on the same machine, just choose a new port, like 123456

$ ./mongod --port 123456 --slave --source mongo.example.com:28017

Now, login  to you slave server’s MongoDB shell and shut it down …

> db.shutdownServer()

Tun your backups and start you slave back … up, again.

Twins Are So Cute

There is no reason your slave sever needs to be as robust as your production server (all you are only using it for backup purposes) … it need only have adequate disk space (so you might want a 64 bit machine if you can.)

So, you can have a “twin” of your production server that looks nothing like your production server (spec wise) kinda like that great Arnold & Danny movie … and your slave might even be a better actor then your master.