Select Page

Prevent Data Loss with MongoDB Backup & Restore

Author: Hanan Alsahsan | | January 22, 2020

In order to prevent a disastrous loss of data, you’ll need to backup your database regularly. Having a good backup and restore strategy in place will help protect your databases and avoid data loss caused by failure(s). The best practice after taking your backup is to test it. It is highly recommended to test your backup it on regular basis. You can achieve that by restoring it to test MongoDB deployment.

The MongoDB backup and restore module provides an essential safety measure for protecting data stored in MongoDB Server databases.

This blog post describes the main methods for backup and restore MongoDB data using the different approaches.

1. Mongodump / mongorestore

mongodump is a utility that performs a backup of MongoDB data. You can use mongodump to backup database, collection based on your specific needs. You can enable consistent snapshot of the data by dumping the oplog.

On the other hand, Mongorestore utility is used to load the dumped BSON data into a newly created or an existing mongod/mongos instance.

It is recommended to use mongodump and mongorestore on small system and not on large system. The reason for that the tools are resource intensive and all data is read through the MongoDB memory while the instance is running.

2. Backup and Restore Underlying Files

You can backup MongoDB by using filesystem snapshots or by copying MongoDB files directly. Filesystem snapshots uses system-level tools to copy database files with minimal downtime and can be used to back up a sharded cluster and a replica set.

The biggest downside of using this method is that you cannot use replica set point in time recovery, because it is not supported.  Also, it is very complicated for large sharded clusters.

There are two options to obtain a coherent snapshot of the MongoDB database:

1. Stop writes and lock databases, followed by using Linux standard file system copy tools such as rsync, cp.

2. Create a snapshot of the entire file system considering the following:

  • Use dedicated mount points for all MongoDB data files.
  • Enable journaling.
  • Disable the balancer and take a same time snapshot from every shard and config server.

Restoring data taken by filesystem snapshot by copying the underlying file is straight forward. You create a new volume and mount it and then restore from the required snapshot or just straight restore to your specific volume.

3. MongoDB Cloud Manager or Ops Manager

MongoDB offers continuously online backup using Ops Manager or MongoDB Cloud Manager.  MongoDB Cloud Manager is online hosted service and Ops Manager is a package both are used to manage MongoDB deployments. They can be used to continually to read the oplog and take backup of replica sets and sharded clusters.

Cloud Manager and Ops manager Backups offer point-in-time recovery and scheduled snapshots and of your MongoDB replica sets and sharded clusters.

Your Backup Workflow described as follow:
1. Activate or install the Backup Agent in your environment.
2. Perform initial sync to MongoDB datacenters.
3. Tailing of the oplog.
4. Snapshots are taken or restored as defined by the user retention policy.

Restore Data with Cloud Manager / Ops Manager

You can restore a standalone MongoDB process, or an entire replica set or sharded cluster using Cloud Manager/Ops Manager. To restore a MongoDB deployment from a backup, select a the wanted snapshot from an existing snapshot list or point in time between existing snapshots.

Snapshot restore can be done automatically, where Cloud Manager / Ops Manager read straight from the snapshot storage. Otherwise, you can manually download the HTTPS link associated with the snapshot files and copy them to your wanted server.

Point in time or a checkpoint restore is done by restoring a full snapshot and then appyling the oplogs until it reaches the specified point specified.

And there you have it. If you’re looking for support for MongoDB, we’re here to help as a MongoDB Premier Partner. We can provide end-to-end solutions customized on what your organization needs. Contact us to learn more.

How to Solve the Oracle Error ORA-12154: TNS:could not resolve the connect identifier specified

The “ORA-12154: TNS:could not resolve the connect identifier specified” Oracle error is a commonly seen message for database administrators.

Vijay Muthu | February 4, 2021

Shortcut to Fixing a Corrupted Oracle Inventory

Oracle Central Inventory files are essential to installing and patching software. The process for fixing a corrupted file can be found here.

Chad Cleveland | February 23, 2016

MongoDB Best Practices: Design, Deployment & More

This post provides a rundown of best practices to use when running MongoDB.

Esayas Aloto | February 28, 2017

Subscribe to Our Blog

Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.

Work with Us

Let’s have a conversation about what you need to succeed and how we can help get you there.


Work for Us

Where do you want to take your career? Explore exciting opportunities to join our team.