// Tutorial //

How to Create and Use MongoDB Backups on Ubuntu 14.04

Published on March 8, 2016
Default avatar
By Hathy A
Developer and author at DigitalOcean.
How to Create and Use MongoDB Backups on Ubuntu 14.04

Introduction

A lot of modern web application developers today choose to use a NoSQL database in their projects, and MongoDB is often their first choice. If you’re using MongoDB in a production scenario, it is important that you regularly create backups in order to avoid data loss. Fortunately, MongoDB offers simple command line tools to create and use backups. This tutorial will explain how to use those tools.

To understand how backups work without tampering with your existing databases, this tutorial will start by walking you through creating a new database and adding a small amount of data to it. You are then going to create a backup of the database, then delete the database and restore it using the backup.

Prerequisites

To follow along, you will need:

Step 1 — Creating an Example Database

Creating a backup of an empty database isn’t very useful, so in this step, we’ll create an example database and add some data to it.

The easiest way to interact with a MongoDB instance is to use the mongo shell. Open it with the mongo command.

  1. mongo

Once you have the MongoDB prompt, create a new database called myDatabase using the use helper.

  1. use myDatabase
Output
switched to db myDatabase

All data in a MongoDB database should belong to a collection. However, you don’t have to create a collection explicitly. When you use the insert method to write to a non-existent collection, the collection is created automatically before the data is written.

You can use the following code to add three small documents to a collection called myCollection using the insert method:

  1. db.myCollection.insert([
  2. {'name': 'Alice', 'age': 30},
  3. {'name': 'Bill', 'age': 25},
  4. {'name': 'Bob', 'age': 35}
  5. ]);

If the insertion is successful, you’ll see a message which looks like this:

Output of a successful insert() operation
BulkWriteResult({
	"writeErrors" : [ ],
	"writeConcernErrors" : [ ],
	"nInserted" : 3,
	"nUpserted" : 0,
	"nMatched" : 0,
	"nModified" : 0,
	"nRemoved" : 0,
	"upserted" : [ ]
})

Step 2 — Checking the Size of the Database

Now that you have a database containing data, you can create a backup for it. However, backups will be large if you have a large database, and in order to avoid the risk of running out of storage space, and consequently slowing down or crashing your server, you should check the size of your database before you create a backup.

You can use the stats method and inspect the value of the dataSize key to know the size of your database in bytes.

  1. db.stats().dataSize;

For the current database, the value of dataSize will be a small number:

Output of db.stats().datasize
592

Note that the value of dataSize is only a rough estimate of the size of the backup.

Step 3 — Creating a Backup

To create a backup, you can use a command-line utility called mongodump. By default, mongodump will create a backup of all the databases present in a MongoDB instance. To create a backup of a specific database, you must use the -d option and specify the name of the database. Additionally, to let mongodump know where to store the backup, you must use the -o option and specify a path.

If you are still inside the mongo shell, exit it by pressing CTRL+D.

Type in the following command to create a backup of myDatabase and store it in ~/backups/first_backup:

  1. mongodump -d myDatabase -o ~/backups/first_backup

If the backup creation is successful, you will see the following log messages:

Successful backup creation logs
2015-11-24T18:11:58.590-0500  writing myDatabase.myCollection to /home/me/backups/first_backup/myDatabase/myCollection.bson
2015-11-24T18:11:58.591-0500  writing myDatabase.myCollection metadata to /home/me/backups/first_backup/myDatabase/myCollection.metadata.json
2015-11-24T18:11:58.592-0500  done dumping myDatabase.myCollection (3 documents)
2015-11-24T18:11:58.592-0500  writing myDatabase.system.indexes to /home/me/backups/first_backup/myDatabase/system.indexes.bson

Note that the backup is not a single file; it’s actually a directory which has the following structure:

Directory structure of a MongoDB backup
first_backup
└── myDatabase
    ├── myCollection.bson
    ├── myCollection.metadata.json
    └── system.indexes.bson

Step 4 — Deleting the Database

To test the backup you created, you can either use a MongoDB instance running on a different server or delete the database on your current server. In this tutorial, we’ll do the latter.

Open the mongo shell and connect to myDatabase.

  1. mongo myDatabase

Delete the database using the dropDatabase method.

  1. db.dropDatabase();

If the deletion is successful, you’ll see the following message:

Output of dropDatabase()
{ "dropped" : "myDatabase", "ok" : 1 }

You can now use the find method of your collection to see that all the data you inserted earlier is gone.

  1. db.myCollection.find();

There will be no output from this command because there’s no data to display in the database.

Step 5 — Restoring the Database

To restore a database using a backup created using mongodump, you can use another command line utility called mongorestore. Before you use it, exit the mongo shell by pressing CTRL+D.

Using mongorestore is very simple. All it needs is the path of the directory containing the backup. Here’s how you can restore your database using the backup stored in ~/backupts/first_backup:

  1. mongorestore ~/backups/first_backup/

You’ll see the following log messages if the restore operation is successful:

Successful restore logs
2015-11-24T18:27:04.250-0500  building a list of dbs and collections to restore from /home/me/backups/first_backup/ dir
2015-11-24T18:27:04.251-0500  reading metadata file from /home/me/backups/first_backup/myDatabase/myCollection.metadata.json
2015-11-24T18:27:04.252-0500  restoring myDatabase.myCollection from file /home/me/backups/first_backup/myDatabase/myCollection.bson
2015-11-24T18:27:04.309-0500  restoring indexes for collection myDatabase.myCollection from metadata
2015-11-24T18:27:04.310-0500  finished restoring myDatabase.myCollection (3 documents)
2015-11-24T18:27:04.310-0500  done

To examine the restored data, first, open the mongo shell and connect to myDatabase.

  1. mongo myDatabase

Then, call the find method on your collection.

  1. db.myCollection.find();

If everything went well, you should now be able to see all the data you inserted earlier.

Output of find()
{ "_id" : ObjectId("5654e76f21299039c2ba8720"), "name" : "Alice", "age" : 30 }
{ "_id" : ObjectId("5654e76f21299039c2ba8721"), "name" : "Bill", "age" : 25 }
{ "_id" : ObjectId("5654e76f21299039c2ba8722"), "name" : "Bob", "age" : 35 }

Conclusion

In this tutorial, you learned how to use mongodump and mongorestore to back up and restore a MongoDB database. Note that creating a backup is an expensive operation, and can reduce the performance of your MongoDB instance. Therefore, it is recommended that you create your backups only during off-peak hours.

To learn more about MongoDB backup strategies, you can refer to the MongoDB 3.0 manual.


Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in our Questions & Answers section, find tutorials and tools that will help you grow as a developer and scale your project or business, and subscribe to topics of interest.

Sign up
About the authors
Default avatar
Hathy A

author

Developer and author at DigitalOcean.

Default avatar
senior technical writer

hi! i write do.co/docs now, but i used to be the senior tech editor publishing tutorials here in the community.


Still looking for an answer?

Was this helpful?

Full disclosure: I work for Elefantos.

Backups are way more than just running a dump command, as any graceful degradation strategy, the devil is in the details.

I wrote a blog post investigating ‘backups’ as a subset of the graceful degradation strategy space (https://www.elefantos.com/blog/simple-complexity), and the gist is that there is no problem in making the actual backup, the complexity is the monitoring and retention policies that you need to implement in order to know if you can use it, in some sense: who watches the watchers.

To be honest from the stories I have heard from my friends and my own experience, I would say backups work about 30% of the time, which is quite horrifying. That is why if you can you should use external service like https://elefantos.com or https://ottomatik.io/ or use your cloud provider to keep your backups safe and monitored.

Hi mongodump -d myDatabase -o ~/backups/first_backup is creating a blank of course is set the “myDatabase” to my database name. What seems to be the problem?

I also tried mongodump -o ~/backups/first_backup for all dbs and same thing too the same thing happens on my ubuntu14.04

Nice! I created a backup ruby script a week ago mit mongodump. Here is my ruby solution in case one has to backup all existing databases.

mUser = ""
mPass = ""
$mongo = Mongo::Client.new(["localhost"], :user => mUser, :password = mPass)
$mongo.database_names.each do |db|
	arg = "mongodump --db \"#{db}\""
	arg << " -u \"#{mUser}\""
	arg << " -p \"#{mPass}\""
	arg << " --authenticationDatabase \"admin\""
	arg << " -o /path/to/backup/"
	`#{arg}`
end

You might also mention that a Backup-User (in case you do not use the root/admin user) with specific privilgeses can be created.

{ 
    "_id" : ObjectId("foo"), 
    "user" : "backupUser", 
    "pwd" : "foo", 
    "roles" : [
        "dbAdminAnyDatabase", 
        "readWriteAnyDatabase", 
        "clusterAdmin", 
        "backup"
    ]
}

great tutorial. I would recommend that obviously, all writing to the mongodb database be stopped prior to doing the mongodump. Moreover, it may be necessary to increase the ulimit before doing the mongorestore, although the number of mongorestore threads can be limited using the “–numParallelCollections” flag . Anyway, these were a couple of the lessons that were learned when I had to do a similar process for a production system.