How to Backup a MongoDB Deployment

How to Backup a MongoDB Deployment

Profile picture for user OnyanchaBrianHenry
Onyancha Brian Henry
31 March 2021


MongoDB deployments can be backed up to a local or a cloud-hosted MongoDB database. To backup standalone mongod processes, you must convert it to a single-member replica set, as only sharded clusters or replica sets can be backed up.

In this blog, we are going to discuss the procedure of backing up a MongoDB deployment. But before getting to the procedure, there are preconditions that must be met so as to successfully backup a MongoDB deployment:

  1. Unique names for deployment items.
  2. Replica set requirements.
  3. Sharded cluster requirements.
  4. MongoDB FCV 4.2 compatibility.
  5. MongoDB compatibility.
  6. Data protection plan.

Unique Names for Deployment Items

Before creating backups make sure your deployment items have unique names. You should note that replica sets, sharded clusters, and shard names within the same project must have unique names for the deployments, failure to do so will result in broken backup snapshots.

Replica Set Requirements

A replica set must:

  • Have an active primary node.
  • Be monitored by the Ops Manager.
  • Run MongoDB version 2.6 or later.
  • Run MongoDB Enterprise with an FCV of 4.2 or later.
  • Have one node with WiredTiger set as its storage engine.

Sharded Cluster Requirements

 For FCV of 4.0 or earlier, a sharded cluster must:

  • Run MongoDB version 2.6 or later.
  • Be monitored by Ops Manager including at least one mongos in the cluster.
  • Complete the balancing round in less than one hour.
  • Have all config servers running. The config server mongod processes must be started with either the --configsvr command line option or the --configsvr { "clusterRole": "configsvr" } setting in the mongod configuration file.

For FCV of 4.2 or later, a sharded cluster must:

  • Be monitored by the Ops Manager.
  • Have an active primary node of each shard and the config server.
  • Have one node per shard or config server with WiredTiger set as its storage engine.
  • Run MongoDB Enterprise with an FCV of 4.2 or later on all nodes including the config server.

MongoDB FCV 4.2 Compatibility and MongoDB Compatibility

For MongoDB FCV 4.2 compatibility, all FCV 4.2 databases must fulfill the appropriate backup considerations. For MongoDB compatibility, the MongoDB version and Ops Manager version must meet the compatibility requirements.

Process of Backing Up a MongoDB Deployment

  1. Click Backup.

Enable the Ops Manager Backup if not yet enabled by clicking the Begin Setup option and complete the wizard hence resulting in a completed backup setup.

  1. Start backing up the process.

From the list of processes, navigate to the Status column for the process you want to backup and click Start.

  1. Set Authentication Mechanisms.

Specify the authentication mechanism and credentials if automation does not manage your deployment and your deployment requires authentication. You should specify the following as appropriate:

  1. Auth Mechanism - Specify the authentication mechanism that the MongoDB host uses, such as; username/password and X.509 Client Certificate for MongoDB, and kerberos and LDAP for MongoDB Enterprise.
  2. DB Username - For username/Password or LDAP authentication, specify the username used to authenticate the MongoDB Agent with the MongoDB deployment.
  3. DB Password - Specify the password used to authenticate the MongoDB Agent with the MongoDB deployment for username/Password or LDAP authentication.
  4. Allows TLS for connections - If checked, Backup uses TLS to connect to MongoDB.

         4. Click start.

Additionally, you should have a data protection plan - protecting your data is just as important as backing it up.

Resyncing a Backup

The Ops Manager gives an alert when a backup becomes out of sync with the MongoDB deployment. In the scenario that you receive the Backup requires a resync alert, you need  to resync the backup for the specified MongoDB instance. The alert means that there isn’t enough data to complete a restore hence the need of resyncing. However, you do not need to resync MongoDB databases that run with an FCV of 4.2.

Scenarios that trigger the alert include:

  • The Oplog has rolled over - this is the most common scenario and it occurs whenever the backup’s tailing cursor cannot keep up with the deployment’s oplog. Without a resync, the backups will not catch up.
  • Unsafe applyOps - occurs when a document that backup does not have a copy of, is indicated.
  • Data corruption - this causes replication leading to breaking of the backup job. When the daemon sees the broken job, it requests a resync.

Data is read from a secondary in each replica set and ops Manager does not produce any new snapshots during the resync process. As a best practice, you should resync all backups annually for production deployments.


To avoid resyncing, ensure the backup oplog does not fall behind the deployment’s oplog. This requires that:

  • You restart the Ops Manager agents in a timely manner following maintenance or other downtime.
  • You ensure the provision of adequate machine resources for the agent.

Make sure that the oplog on the primary is large enough to contain at least 24 hours of activity so as to buffer against maintenance and occasional activity bursts. Also, ensure that the head database takes the new index into account by resyncing the head database after you create an index in a rolling fashion.

Process of Resyncing a Backup

  1. Click Backup, then navigate to the Overview tab.
  2. On the line listing the process, click the ellipsis icon and then click Resync.
  3. Click the Resync button. If prompted for an authentication code, enter the code and click Verify then click Resync again.


To sum up, MongoDB deployments can be backed up either to a local or a cloud-based MongoDB instance. We hope that this blog has provided you with some insight on how to do that. Before backing up your data ensure that your backups have unique names, adhere to the replica set or sharded cluster requirements and follow the process of backing up your MongoDB data and you should be well on your way to performing backup operations successfully.