You were redirected from a different version of the documentation. Click here to go back.

Install the Ops Manager Application Database and Backup Database

Before you install Ops Manager, you must deploy its supporting databases. These are called backing databases. These databases include the Ops Manager Application Database and the backup database. The following table compares the Ops Manager Application Database and the Backup Database:

Frequently Asked Questions Application Database Backup Database
What does the database store?


The following items can contain sensitive data. To prevent unauthorized access and protect sensitive data, you must secure the Ops Manager Application Database.

  • Oplog data
  • Temporary sync data
  • Your snapshots, depending on your configuration
Is the database necessary? Yes No, unless you use Ops Manager to backup the databases that Ops Manager manages.
How should the database store the data? Dedicated replica set on independent storage volume Dedicated replica set per backup database on independent storage volumes
Can the database use more than one deployment? No Yes
Can Ops Manager use the Automation module with this database? No Yes
Can Ops Manager use the Backup Module to back up this database? No No
Can Ops Manager use the Monitoring module to monitor this database? Yes Yes


Each backing database must use a dedicated replica set. The replica set can’t store other data.

Running regular backups, a backup database could fill a volume. If the application database cannot write to a volume, Ops Manager stops. Proper storage setup reduces the risk of Ops Manager failures.


Replica Set Topology

Each backing database replica set should include three data-bearing members for high availability. If you lack storage capacity for three data-bearing members, the third member of a backing database may be an arbiter.

For the Ops Manager application database, you may run one member of the replica set on the same host as Ops Manager.

Backing Databases with fewer than three data-bearing members

When writing to its backing databases, Ops Manager uses the Replica Acknowledged (w:2) write concern. This write concern reports a write as successful only after the primary and one secondary acknowledge that write. This means that if a backing database loses one of the two data-bearing members, MongoDB stops write operations.

Application Database Monitoring

You can choose to monitor the application database after you install Ops Manager.

To monitor your application database:

  1. Finish installing the backing databases.
  2. Install Ops Manager Application.
  3. Enable Monitoring for the application database.
    1. Install the MongoDB Agent on the application database hosts.
    2. Add the application database through the Ops Manager UI.

See also

To follow the full procedure, see Enable Application Database Monitoring.


Replica Set Configuration

The replica sets that host the Ops Manager backing databases must:

Use Dedicated Databases

The replica sets must store data to support Ops Manager metadata only. They must store no other data.

Use Backing Database for S3 Block and Oplog Metadata

If you use S3 for block or oplog storage, the backing database can store the metadata for the blocks and oplog.

Use a Compatible MongoDB Version

For the following Ops Manager release series, you may run its backing databases on any of the following MongoDB versions:

Supported Versions of MongoDB for Each Version of Ops Manager
Ops Manager Release MongoDB 4.2 MongoDB 4.4 MongoDB 5.0 MongoDB 6.0
Ops Manager 5.0 check square icon check circle icon check circle icon  
Ops Manager 6.0   check square icon check circle icon check circle icon

check circle icon Supported check square icon Deprecated

Version support covers the full release series from the first to the last release.

To learn more about MongoDB versioning, see MongoDB Versioning in the MongoDB Manual.


Only the MongoDB Ops Manager backing databases must meet this requirement. The MongoDB deployments that Ops Manager manages do not. For the minimum versions required for managed MongoDB deployments, see MongoDB Compatibility Matrix.

Use the WiredTiger Storage Engine for the Application Database

Use WiredTiger for the Ops Manager application database.

Use the WiredTiger Storage Engine for the Backup Database

For backup database configuration options, see Backup Preparations.

Use Queries that Do Not Require Indexes

Do not run the backing databases with the MongoDB --notablescan parameter set. When set, this parameter specifies that all queries must use indexes.

Replica Set Security

Secure the Connection to the Backing Databases

Ensure that connections from Ops Manager to your backing databases are secure. Configure these databases to accept connections from Ops Manager that only use TLS.

Configure an Authentication Mechanism for the Backing Databases

Limit access to your backing databases to specific MongoDB users using an authentication mechanism. To configure your backing databases to use authentication, see Configure Ops Manager to Authenticate with Application Databases.

Grant Minimal Roles to the Ops Manager User that Accesses the Backing Databases

Set these users to have the readWriteAnyDatabase and dbAdminAnyDatabase roles. If a backing database is a sharded cluster, add clusterAdmin, otherwise add clusterMonitor.

Host Configuration

The hosts that run the replica sets must meet the following requirements for:


The hosts must meet Ops Manager Application Database Hardware Requirements or Backup Database Hardware Requirements depending on which database the host runs. If a host serves other Ops Manager components in addition to the database, you must sum the hardware requirements for each component to determine the requirements for the host.

System Configuration

The hosts must be configured according to the requirements given in the MongoDB Production Notes except where explicitly contradicted in this tutorial. The Production Notes include information on ulimits, NUMA, and other configuration options.


Use lowercase FQDNs. If you use uppercase characters, Ops Manager may fail to find your backing database. To learn more about naming hosts, see RFC 1178.


Host network security must allow the needed ports described in Firewall Configuration. The appropriate inbound and outbound firewall rules for each host must allow access to the required ports.

RHEL and CentOS 6 hosts only

RHEL and CentOS 6 limit the maximum number of user processes to 1024. This overrides the general user process limit (ulimit -u) setting.

For the userid that runs Ops Manager (mongodb-mms by default), add soft and hard nproc (number of processes) entries to the /etc/security/limits.d/99-mongodb-nproc.conf user process configuration file. Use values that are larger than the RHEL 1024 user process limit.

mongodb-mms soft nproc 200000
mongodb-mms hard nproc 500000

If /etc/security/limits.d/99-mongodb-nproc.conf does not exist, create it. Use the contents of the /etc/security/limits.d/90-nproc.conf file as a template.

RHEL and CentOS hosts running SELinux in enforcing mode

If the hosts are not configured to use the default MongoDB data or log paths or ports and are enforcing SELinux policies, update the SELinux policies before starting the backing databases.

To learn how to update the SELinux policy:

Deploy Backing Databases

To deploy MongoDB replica sets to host the Ops Manager backing databases:


Provision hosts.

Your hosts must meet the Host Configuration requirements.


Make sure you configure the MongoDB deployment for your backing databases according to the MongoDB Production Notes. If you do not, this MongoDB deployment may fail.


Install MongoDB on each host.

Follow the Install MongoDB procedure in the MongoDB manual. If you choose to install MongoDB Enterprise for the backing database, you must install the MongoDB Enterprise dependencies, as described in those same install procedures.

Next Steps