Navigation
This version of the documentation is archived and no longer supported. It will be removed on EOL_DATE. 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.
This version of the manual is no longer supported. It will be removed on EOL_DATE.

Glossary

agent

One of several lightweight programs that run within your network to monitor, manage, and back up your MongoDB databases.

See Automation Agent, Monitoring Agent and Backup Agent.

agent API key

A unique identifier that authenticates a project’s agents to Ops Manager. A project can have multiple agent API keys.

See Manage Agent API Keys.

Ops Manager Application

The main Ops Manager component. The Ops Manager Application provides the user interface for managing MongoDB deployments and provides endpoints for Ops Manager agents to transmit data.

See Ops Manager Application.

application database

The dedicated set of MongoDB databases that store metadata for the Ops Manager installation and the managed MongoDB deployments.

See Ops Manager Application Database.

authentication mechanism

A method to enable access to a MongoDB database. This is separate from authorization, which grants you permission to use certain actions on a MongoDB database.

See Configure MongoDB Authentication and Authorization.

automation

The assisted management of MongoDB processes through the Ops Manager interface. Automation Agents installed on your MongoDB servers allow you to deploy, configure, and update MongoDB processes directly from Ops Manager.

See Automation.

Automation Agent

A lightweight component that automates common management tasks. The Automation Agent runs on every server that will have a mongod or mongos.

See Automation Agent.

backing databases

The collective term for the sets of MongoDB databases that support an Ops Manager deployment: the application database and the backup database(s).

See Install the Ops Manager Application Database and Backup Database.

Backup Agent

A lightweight component that runs within your data center and backs up MongoDB processes via the MongoDB wire protocol. No direct file system access is needed.

See Backup Agent.

Backup Blockstore Database
The database that stores your snapshots. The database is also referred to simply as the blockstore. The blockstore uses a storage format that parses a snapshot into smaller chunks that allow Ops Manager to manage snapshot changes. You can administer blockstores from the Snapshot Storage. The blockstore is one type of Backup Database.
Backup Daemon

The Ops Manager component that creates and manages backups by maintaining head databases and snapshots.

See Backup Daemon Service.

Backup Database

The set of databases where Ops Manager stores backup data. This includes the Oplog Store Database and any Backup Blockstore Database or S3 Snapshot Store metadata database deployed.

See Snapshot Storage and Backup Process.

backup job

The Backup Daemon runs this process to apply the most recent changes to its backup of a replica set. The daemon stores backups locally as head databases. A sharded cluster will have a different head database for each shard. You can re-assign backup jobs among Backup Daemons.

See Jobs.

batch

The collection of jobs needed to restore a sharded cluster: one job for each shard and one job for the config server.

Replica set restore jobs do not use batches.

block
A MongoDB document that stores the compressed contents of a 64 KB to 16 MB slice of the data and metadata of a file included in a snapshot. In dividing the snapshot, Ops Manager can back up data block by block instead of writing whole new copies of a snapshot.
blockstore
See Backup Blockstore Database.
checkpoint

A point in time between snapshots to which you can restore a sharded cluster. Ops Manager must stop the balancer each time it creates a checkpoint. Ops Manager does not require checkpoints, and they are disabled by default.

See Checkpoints.

cluster
In Ops Manager, cluster can refer to either a replica set or sharded cluster.
conf call

A request from an agent to Ops Manager to get the latest configuration for the agent’s project.

For the Backup Agent, this configuration includes the nodes to which the agent connects and what data to back up.

custom snapshot

A backup of the state of your MongoDB deployment at a point in time between stored snapshots. Ops Manager builds a custom snapshot by applying oplog data to a stored snapshot.

See Restore Overview.

deduplication

A process that eliminates redundant data. This data can be additional copies of database or file system documents or redundant data within those documents at the block level when written to a storage medium like spinning or solid state disks. Only unique documents or blocks are written to a storage medium. This process usually applies to backups or data archiving.

Example

Each recipient in an email system may have their own copy of an email sent to the whole company. With deduplication, all copies of this except one are replaced with pointers to a single stored copy before backing up the email system. This effectively reduces the amount of storage capacity needed to back up this one email by 99 percent.

deployment
Usually refers to all the MongoDB processes that run within an Ops Manager project. Deployment can also refer to a specific set of MongoDB processes, such as a specific sharded cluster or replica set.
dirty bytes
Data that has been updated in the WiredTiger cache but not flushed to disk.
excluded namespace

A database or collection that Ops Manager will not back up, as designated by its namespace.

See Namespaces Filter.

File System Store
A directory on a server that stores your database backup snapshots as files. You can administer file system storage from the Snapshot Storage.
groom
A job that removes unused blocks on a blockstore and that can move blocks from one blockstore to another. You can view and manage grooms from Grooms and Groom Priority.
group

A distinct set of MongoDB processes and Ops Manager users. Synonymous with project.

See Projects.

head
See head database.
head database
The copy of a backed-up deployment stored on the Backup Daemon’s server. The daemon maintains a head database for each shard or replica set it backs up and creates periodic snapshots. The daemon stores the head databases in the head directory.
head directory
The dedicated disk partition on the Backup Daemon’s server where the Backup Daemon stores the head databases. The daemon writes to this directory as the mongodb-mms user.
HTTP Service

The interface through which the Monitoring Agent communicates with Ops Manager.

See Ops Manager Application.

initial sync

The MongoDB operation that replicates data from an existing replica set member to a new member. Ops Manager uses initial sync when creating a new head database.

See Backup Process Flows.

See also Replica Set Data Synchronization in the MongoDB manual.

job
See backup job.
monitoring
The real-time reporting, visualization, and alerting of the state of your MongoDB processes. See Monitoring.
Monitoring Agent
A lightweight component that runs within your data center and monitors your MongoDB processes via the MongoDB wire protocol. No direct file system access is needed. See Monitoring Agent.
namespace

The combination of the database name and collection name:

[database-name].[collection-name]

oplog slice

A compressed batch of entries for the tailed oplog of a backed-up shard or replica set. The Backup Agent creates an oplog slice and sends it to Ops Manager, which stores it in the Oplog Store Database.

The Backup Daemon retrieves the slice and applies it to the associated head database.

See Oplog Stores.

Oplog Store Database

The database where Ops Manager stores oplog slices before applying them to a deployment’s backup.

See Oplog Stores.

ping
A data transmission sent by the Monitoring Agent to Ops Manager to confirm that the agent and its MongoDB processes are running and reachable.
point-in-time restore

A database restoration that captures the state of your data at a moment in-between snapshots. Point-in-time restores take longer to perform than snapshot restores.

See Restore Overview.

process

An instance of MongoDB running on a given host and port. The MongoDB database process is mongod. MongoDB also uses the mongos process to route operations in the sharded clusters.

See MongoDB Package Components in the MongoDB manual.

project

A distinct set of MongoDB processes and Ops Manager users. Synonymous with group.

See Projects.

Public API key
A unique identifier that authenticates an Ops Manager user through the Public API. The key belongs to the user, as opposed to the agent API key, which belongs to the project.
queryable backup

A feature provided by Ops Manager in which Ops Manager quickly and securely makes a given snapshot accessible over a MongoDB connection string. You can use the connection string with standard MongoDB tools such as the mongo shell or mongodump to access the snapshot for read-only operations.

Queryable backups start up quickly regardless of the snapshot’s total data size. They are uniquely useful for restoring a small subset of data, such as a document that was accidentally deleted, or reading out a single collection with mongodump.

See Query a Backup Snapshot.

Recovery Point Objective
The maximum tolerable age of backup files that must be recovered from storage for normal operations to resume after a failure or disaster occurs.
Recovery Time Objective
The maximum tolerable length of time that a system can be offline after a failure or disaster occurs.
role

The access given to an Ops Manager or MongoDB user.

rolling restart
A technique used to maintain cluster availability during maintenance periods by updating nodes in a replica set one-by-one, always maintaining a primary node, until all nodes are updated.
S3 Snapshot Store

An S3 bucket in Amazon Web Services that stores your database backup snapshots as blocks. You can administer S3 blockstore storage from the Snapshot Storage.

See Manage S3 Blockstore Snapshot Storage.

server
A physical or virtual machine that hosts one or more MongoDB processes.
server pool

A supply of pre-provisioned servers available for new MongoDB clusters and standalone processes. The servers in the pool have Automation Agents already installed. Ops Manager administrators maintain the server pool.

See Provision Servers for the Server Pool and Request Provisioned Servers from the Pool.

Server Pools deprecated as of Ops Manager 4.0

As of Ops Manager 4.0, server pools are deprecated and disabled by default.

snapshot

A backup of your data captured at a specific interval and stored in either a blockstore or a file system. Ops Manager creates snapshots from the backups kept on the head databases. The Snapshot Frequency and Retention Policy determines the interval for taking snapshots and how long to store them.

See also custom snapshot.

snapshot frequency and retention policy

The schedule for how often to take snapshots and how long to store them.

See Snapshot Frequency and Retention Policy.

snapshot store
The location where your snapshots are stored. There are multiple types of snapshot stores, including File System Stores, Blockstores and S3 snapshot stores.
storage engine

The database storage engine manages how data is stored on disk. MongoDB versions 3.0 and higher offer multiple storage engines.

See Storage and FAQ: MongoDB Storage in the MongoDB manual.

sync store
During initial sync of a backed-up deployment, Ops Manager briefly stores slices of the backed-up deployment in a temporary sync store on the Application Database. Ops Manager uses the storage while streaming slices to the Backup Daemon.
version manifest
The list of all released MongoDB versions that a particular version of Ops Manager supports. Ops Manager uses this list if running in local mode.