This version of the documentation is archived and no longer supported. To learn how to upgrade your version of MongoDB Ops Manager, refer to the upgrade documentation.
You were redirected from a different version of the documentation. Click here to go back.

Frequently Asked Questions

This document addresses common questions about Ops Manager and its use.

What versions of MongoDB does Ops Manager manage?

For specific Ops Manager functions and supported MongoDB versions, see MongoDB Compatibility Matrix.

What are the upgrade paths for Ops Manager versions 1.8.x and 2.0.x?

For upgrade paths, see Upgrade Ops Manager.

Automation FAQs

Ops Manager can automate management operations for your monitored MongoDB processes, allowing you to reconfigure, stop, and restart MongoDB through the Ops Manager interface.

Ops Manager Automation can run only on 64-bit architectures.

How does Ops Manager manage MongoDB deployments?

After you deploy the Automation Agent in the environment of the MongoDB deployment, each agent periodically communicates with Ops Manager and performs any required work.

Agents constantly reassess their environment to adapt their work as necessary. If an agent encounters an issue, such as network connectivity problems or Ops Manager failure, the agents adjust their work to compensate and safely arrive at their goal state.

Agents create plans to move from their current state to a goal state. Plans execute in steps, where each step is autonomous and independent of other steps.

For example, for an installation, the plan involves downloading MongoDB, starting the process with the appropriate command line options, initializing the replica set, waiting for a healthy majority. The configuration reaches goal state when the replica set is active and has a healthy majority.

How many Automation Agents do I need?

To use Automation, you must have an agent running on every host where a managed MongoDB instance runs.

Is any MongoDB data transferred by the Automation Agent?

Agents do not transmit any data records from a MongoDB deployment. The agents only communicate deployment configuration information and MongoDB logs.

Will Ops Manager handle failures during an upgrade, such as Ops Manager going down or a network partition?

Generally speaking, yes. The design of the management and automation components of Ops Manager do not account for all possible failures; however the architecture of the system can work around many types of failures.

What types of deployment can I create in Ops Manager?

Using Ops Manager, you can configure all MongoDB deployment types: sharded clusters, replica sets, and standalones.

The shards in a sharded cluster must be replica sets. That is, a shard cannot be a standalone mongod. If you must run a shard as a single mongod (which provides no redundancy or failover), run the shard as a single-member replica set.


You may not upgrade a sharded MongoDB deployment to version 3.4 if the deployment uses mirrored mongod instances as config servers. To allow the sharded deployment to be upgraded, see Convert Config Servers to a Replica Set. The conversion requires that the sharded deployment run MongoDB version 3.2.4 or later. Deployments running previous versions must upgrade to version 3.2.4 before an upgrade to version 3.4.

Monitoring FAQs

Host Configuration

How do I add a new host or server?

See Add Existing MongoDB Processes to Ops Manager.

Can Ops Manager monitor itself?

Yes. You can use Ops Manager to monitor the backing MongoDB instances that hold data for Ops Manager and the Backup Daemon. Create a separate project for the backing instances.

You cannot, however, use Ops Manager to backup or automate the backing instances.

Ops Manager also provides built-in basic monitoring of all backing databases through system alerts.

Can I monitor Kerberos-enabled instances?

Yes. Ops Manager does support monitoring for Kerberos-enabled MongoDB instances. See Configure the Monitoring Agent for Kerberos for more information.

Monitoring Agent

Do I need a Monitoring Agent for every MongoDB instance?

No. In your Ops Manager project, a single Monitoring Agent connects to all MongoDB databases. Configure firewalls to allow the Monitoring Agent to connect across data centers and servers.

Beginning with Monitoring Agent version 5.0.0, you can run multiple agents to to distribute monitoring assignments and provide failover. Ops Manager distributes monitoring assignments among up to 100 running Monitoring Agents. If you run more than 100 Monitoring Agents, the additional agents behave as “standby” agents. For more information, see Multiple Monitoring Agents.

Where should I run the Monitoring Agent?

The amount of resources the Monitoring Agent requires varies depending on infrastructure size, the number of servers and the databases it is monitoring. Run the agent on an existing machine with additional capacity that does not run a mongod instance. You may also run the Monitoring Agent on a smaller dedicated instance.

The Monitoring Agent load scales with the number of monitored mongod plus mongos processes and the number of databases in your MongoDB environment.

For production environments, it is recommended to install the Monitoring Agent on a dedicated server, and not on the the same host as a data bearing mongod instance. This allows you to perform maintenance on the mongod and its host without affecting the monitoring for your deployment. Additionally, a Monitoring Agent may contend for resources with the mongod.

You can install the Monitoring Agent on the same system as an arbiter, a mongos, or an application server depending on the requirements of these services and available resources.

Can I run the Monitoring Agent on an AWS micro server?

If you monitor five or fewer mongod instances, you can use a AWS micro server.

Why can’t the Monitoring Agent connect to my host?

The most common problem is that the agent is unable to resolve the hostname of the server. Check DNS and the /etc/hosts file.

The second most common problem is that there are firewall rules in place that prohibit access to the server from the agent.

To test the connection, login to the server running the agent and try to connect using the mongo shell:

mongo hostname:port/test


Ops Manager does not support port forwarding.

Why does the Monitoring Agent connect with hostnames instead of IP addresses?

By default, the Monitoring Agent tries to connect by resolving hostnames. If the agent cannot connect by resolving a hostname, you can force the Monitoring Agent to prefer an IP address over its corresponding hostname for a specific IP address. Preferred hostnames also allow you to specify the hostname to use for servers with multiple aliases. This prevents servers from appearing multiple times under different names in the Ops Manager interface.

To create a preferred hostname, go to Project Settings and add a Preferred Hostnames entry. For details, see Edit Project Settings

How do I setup and configure the agent?

See the README file included in the agent download.

How do I delete a Monitoring Agent from Ops Manager?

See Remove Monitoring Agents from Ops Manager.

Data Presentation

What are all those vertical bars in my charts?

A red bar indicates a server restart.

A orange bar indicates the server is now a primary.

A brown bar indicates the server is now a secondary.

Data Retention

What is the data retention policy for Ops Manager?

Ops Manager retains two distinct types of data: metrics, which describe usage; and snapshots, which back up your data.

Ops Manager preserves:

  • Ops Manager preserves metric data according to Ops Manager’s Monitoring Data Retention settings. Ops Manager administrators can modify the settings by selecting Admin, then General, then Ops Manager Config, then the Miscellaneous tab, and then scrolling to Default Monitoring Data Retention.
  • Snapshots according to their retention policy.

Backup FAQs

Ops Manager creates backups of MongoDB replica sets and sharded clusters. After an initial sync, Ops Manager tails the operation log (oplog) to provide a continuous backup with point-in-time recovery of replica sets and consistent snapshots of sharded clusters. For more information, please review these frequently asked questions.


What version of MongoDB does the Backup feature require?

For information on compatibility, see MongoDB Compatibility Matrix.

What MongoDB permissions does the Backup Agent require?

If you are backing up a MongoDB instance that has authentication enabled, the Backup Agent requires elevated privileges, as described in Required Access for Backup Agent.

Are there any limits to the types of deployments the Backup feature supports?

Yes. Backup does not currently support standalone deployments. Backup has full support for replica sets and sharded clusters.

Why doesn’t the Backup feature support standalone deployments?

After an initial sync of your data, Ops Manager copies data from the oplog to provide a continuous backup with point-in-time recovery. Ops Manager does not support backup of standalone servers, which do not have an oplog. To support backup with a single mongod instance, you can run a one-member replica set.

How Does Ops Manager Measure Data Size?

Ops Manager uses the following conversions to measure snapshot size and to measure how much oplog data has been processed:

  • 1 MB = 10242 bytes
  • 1 GB = 10243 bytes
  • 1 TB = 10244 bytes


How does the Backup Feature work?

You install the Backup Agent on a server in the same deployment with your MongoDB infrastructure. The agent conducts an initial sync of your data to Ops Manager. After the initial sync, the agent tails the oplog to provide a continuous backup of your deployment.

Where should I run the Backup Agent?

Run the Backup Agent on a host that:

  • Is separate from your MongoDB instances. This avoids system resource contention.
  • Can connect to your MongoDB instances. Check network settings for connections between the agent and MongoDB hosts. For a list of needed ports, see open ports for agents.
  • Has at least 2 CPU cores and 3 GB of RAM above platform requirements. With each backup job it runs, the Backup Agent further impacts host performance.

Can I run the Backup and Monitoring Agents on a Single System?

There is no technical restriction that prevents the Backup Agent and the Monitoring Agent from running on a single system or host. However, both agents have resource requirements, and running both on a single system can affect the ability of these agents to support your deployment in Ops Manager.

The resources required by the Backup Agent depend on rate and size of new oplog entries (i.e. total oplog gigabyte/hour produced.) The resources required by the Monitoring Agent depend on the number of monitored mongod instances and the total number of databases provided by the mongod instances.

Can I run multiple Backup Agents to achieve high availability?

You can run multiple Backup Agents for high availability. If you do, the Backup Agents must run on different hosts.

When you run multiple Backup Agents, only one agent per project is the primary agent. The primary agent performs the backups. The remaining agents are completely idle, except to log their status as standbys and to periodically ask Ops Manager whether they should become the primary.

Does the Backup Agent modify my database?

The Backup Agent writes a small token called a “checkpoint” into the oplog of the source database at a regular interval. These tokens provide a heartbeat for backups and have no effect on the source deployment. Each token is less than 100 bytes. See: Checkpoints for more information about checkpoints.

Will Backup impact my production databases?

The Backup feature will typically have minimal impact on production MongoDB deployments. This impact will be similar to that of adding a new secondary to a replica set.

By default, the Backup Agent will perform its initial sync, the most resource intensive operation for backups, against a secondary member of the replica set to limit its impact. You may optionally configure the Backup Agent to perform the initial sync against the replica set’s primary, although this will increase the impact of the initial sync operation.

What is the load on the database during the initial Backup sync?

The impact of the initial backup synchronization should be similar to syncing a new secondary replica set member. The Backup Agent does not throttle its activity, and attempts to perform the sync as quickly as possible.

How do I perform maintenance on a Replica Set with Backup enabled?

Most operations in a replica set are replicated via the oplog and are thus captured by the backup process. Some operations, however, make changes that are not replicated: for these operations you must have Ops Manager resync from your current replica set to include the changes.

The following operations are not replicated and therefore require resync:

  • Renaming or deleting a database by deleting the data files in the data directory. As an alternative, remove databases using an operation that MongoDB will replicate, such as db.dropDatabase() from the mongo shell.

  • Changing any data while the instance is running as a standalone.

  • Rolling index builds.

  • Using compact or repairDatabase to reclaim a significant amount of space.

    Resync is not strictly necessary after compact or repairDatabase operations but will ensure that the Ops Manager copy of the data is resized, which means quicker restores.


How can I prevent Ops Manager from backing up a collection?

Ops Manager provides a namespaces filter that allows you to specify which collections or databases to back up.

How can I change which namespaces are backed up?

To edit the filter, see Edit a Backup’s Settings. Changing the namespaces filter might necessitate a resync. If so, Ops Manager handles the resync.

How can I use Backup if Backup jobs fail to bind?

The most common reason that jobs fail to bind to a Backup Daemon is because no daemon has space for a local copy of the backed up replica set.

To increase capacity so that the backup job can bind, you can:

  • add an additional backup daemon.
  • increase the size of the file system that holds the Head directory.
  • move the Head database data to a new volume with more space, and create a symlink or configure the file system mount points so that the daemon can access the data using the original path.

How do I resolve applyOps errors during backups?

If you notice consistent errors in applyOps commands in your Backup logs, it may indicate that the daemon has run out of space.

To increase space on a daemon to support continued operations, you can:

  • increase the size of the file system that holds the Head directory.
  • move the Head database data to a new volume with more space, and create a symlink or configure the file system mount points so that the daemon can access the data using the original path.


Ops Manager produces a copy of your data files that you can use to seed a new deployment.

How does Ops Manager provide point-in-time restores?

Ops Manager first creates a local restore of a snapshot preceding the point in time and then applies the stored oplog entries to reach the specified point in time.

The ability of Ops Manager to provide a given point-in-time restore depends on the retention policy of the snapshots and the configured point-in-time window.

For information on retention policy and the point-in-time window, see Edit Snapshot Schedule and Retention Policy.

Can I take snapshots more frequently than every 6 hours?

No, Ops Manager does not support a snapshot schedule more frequent than every 6 hours. For more information, see Snapshot Frequency and Retention Policy.

Can I set my own snapshot retention policy?

Yes. You can change the schedule through the Edit Snapshot Schedule menu option for a backed-up deployment. Administrators can change the snapshot frequency and retention policy through the snapshotSchedule resource in the API.

How long does it take to create a restore?

Ops Manager transmits all backups in a compressed form from the Ops Manager server to your infrastructure.

In addition, point-in-time restores that require creating a new snapshot take additional time, which depends on the size of the scheduled snapshot and the amount the oplog entries that Ops Manager must apply to the preceding snapshot to roll forward to the requested point-in-time of the backup.

Does the Backup feature perform any data validation?

Backup conducts basic corruption checks and provides an alert if any component (e.g. the agent) is down or broken, but does not perform explicit data validation. When it detects corruption, Ops Manager errs on the side of caution and invalidates the current backup and sends an alert.

How do I restore? What do I get when I restore?

You can request a restore via Ops Manager, where you can then choose which snapshot to restore and how you want Ops Manager to deliver the restore. All restores require 2-factor authentication. If you have SMS set up, Ops Manager will send an authorization code via SMS. You must enter the authorization code into the backup interface to begin the restore process.


From India, use Google Authenticator for two-factor authentication. Google Authenticator is more reliable than authentication with SMS text messages to Indian mobile phone numbers (i.e. country code 91).

Ops Manager delivers restores as tar.gz archives of MongoDB data files.

For more information, see Restore MongoDB Deployments.

How does Ops Manager handle a rollback of backed-up data?

If your MongoDB deployment experiences a rollback, then Ops Manager also rolls back the backed-up data.

Ops Manager detects the rollback when a tailing cursor finds a mismatch in timestamps or hashes of write operations. Ops Manager enters a rollback state and tests three points in the oplog of your replica set’s primary to locate a common point in history. Ops Manager rollback differs from MongoDB secondary rollback in that the common point does not necessarily have to be the most recent common point.

When Ops Manager finds a common point, the service invalidates oplog entries and snapshots beyond that point and rolls back to the most recent snapshot before the common point. Ops Manager then resumes normal backup operations.

If Ops Manager cannot find a common point, a resync is required.

What conditions will require a resync?

If the Backup Agent’s tailing cursor cannot keep up with your deployment’s oplog, then you must resync your backups.

This scenario might occur, for example, if:

  • Your application periodically generates a lot of data, shrinking the primary’s oplog window to the point that data is written to the oplog faster than Ops Manager can consume it.
  • If the Backup Agent is running on an under-provisioned or over-used machine and cannot keep up with the oplog activity.
  • If the Backup Agent is down for a period of time longer than the oplog size allows. If you bring down your agents, such as for maintenance, restart them in a timely manner. For more information on oplog size, see Replica Set Oplog in the MongoDB manual.
  • If you delete all replica set data and deploy a new replica set with the same name, as might happen in a test environment where deployments are regularly torn down and rebuilt.
  • If there is a rollback, and Ops Manager cannot find a common point in the oplog.
  • If an oplog event tries to update a document that does not exist in the backup of the replica set, as might happen if syncing from a secondary that has inconsistent data with respect to the primary.

Administration FAQs

Can I reset my password?

Yes, see Edit Personal Settings.

How do I add a user to my organization or project?

For instructions on adding users to your organization or project, see Ops Manager Users and Teams.

How can I configure multiple Google Authenticator apps to use the same account?

By selecting the Can’t scan the barcode? option during the procedure to Configure Two-Factor Authentication. The option provides a common key that multiple Google Authenticator apps can use.

What do the alert conditions mean?

For a reference on the alert conditions, see Alert Conditions.

What alerts are configured by default?

See Manage Alert Configurations for the default alert configurations as well as steps to add new alerts or modify existing alerts, including modifying the alert frequency.

How do I close my Ops Manager project?

A user with the Project Owner access for the projects can close a project.

You can delete a project from the project’s Settings page. For details, see Delete a Project.

The operation cannot be undone.


What open source projects does Ops Manager use?

App framework
Google Guice
HTTP server
Web framework
Miscellaneous server libraries
Apache Commons
User interface libraries
jQuery, Bootstrap
←   Backup Reference  →