> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Ops Manager Architecture An Ops Manager installation includes hosts that run the Ops Manager Application and hosts that serve and store application data and snapshots. ![Network diagram showing flows of data between Ops Manager's components.](/images/ops-manager-overview.png) The Ops Manager Application requires a dedicated [Application Database](https://www.mongodb.com/docs/ops-manager/current/reference/glossary/#std-term-application-database) and, if you enabled backups, [Snapshot Stores.](https://www.mongodb.com/docs/ops-manager/current/reference/glossary/#std-term-snapshot-store) ## Ops Manager Application The Ops Manager Application provides the user interface and the HTTP (Hypertext Transfer Protocol) services the MongoDB Agent uses to transmit data to and from Ops Manager. These are all stateless and start automatically when the Ops Manager Application starts. Multiple instances of the Ops Manager Application can run if each instance uses the same configuration and the same application database. Users and Agents can interact with any instance. By default, the Ops Manager Application runs on port `8080` and contains the web interface for managing Ops Manager users, monitoring of MongoDB hosts, and managing host backups. For a list of Ops Manager's default ports and health-check endpoints, see [Firewall Configuration.](https://www.mongodb.com/docs/ops-manager/current/reference/firewall-configuration.md) ## Backup Daemon Service You can configure any Ops Manager instance to perform backup [snapshot](https://www.mongodb.com/docs/ops-manager/current/reference/glossary.md#std-term-snapshot) maintenance work, such as a [grooms](https://www.mongodb.com/docs/ops-manager/current/reference/glossary.md#std-term-groom) and managing file system snapshot files on the [file system store](https://www.mongodb.com/docs/ops-manager/current/reference/glossary.md#std-term-File-System-Store) by running the [Backup Daemon](https://www.mongodb.com/docs/ops-manager/current/reference/glossary.md#std-term-Backup-Daemon). To learn how to start, check the status of, stop, and restart the Backup Daemon on a server, see [Manage the Backup Daemon.](https://www.mongodb.com/docs/ops-manager/current/tutorial/manage-backup-daemon.md#std-label-manage-backup-daemon) How the Backup Daemon performs depends upon the [`MongoDB version compatibility`](https://www.mongodb.com/docs/manual/reference/command/setFeatureCompatibilityVersion.md#mongodb-dbcommand-dbcmd.setFeatureCompatibilityVersion) of your database. This Feature Compatibility Version ranges from the current version to one version earlier. For example, with MongoDB 4.4, the FCV can be `4.2` or `4.4`. Backup functionality changed with [FCV](https://www.mongodb.com/docs/manual/reference/command/setFeatureCompatibilityVersion/#mongodb-dbcommand-dbcmd.setFeatureCompatibilityVersionbon.mon) `4.2`. The Backup Daemon service provides the following services for databases: - Runs groom jobs, incremental filesystem snapshots, other backup related jobs - Performs some state updates to the backup job - Perform a queryable restore Client applications can't communicate with the daemon. Its state and job queues come from the [Ops Manager Application Database](https://www.mongodb.com/docs/ops-manager/current/core/system-overview.md#std-label-mms-application-database). Ops Manager creates snapshots from the database being backed up. For incremental backups using file system stores, the daemon is responsible for creating snapshots. [Multiple Backup Daemons](https://www.mongodb.com/docs/ops-manager/current/tutorial/configure-backup-high-availability.md#std-label-multiple-backup-daemons) can scale horizontally to run more concurrent jobs when needed and can provide *manual* failover. If you run multiple Backup Daemons, Ops Manager selects the Backup Daemon to use when a user enables backup for a deployment. The [head database](https://www.mongodb.com/docs/ops-manager/current/reference/glossary/#std-term-head-database) resides with the daemon's host. ## Dedicated Storage for Operational Data ### Ops Manager Application Database Ops Manager uses a dedicated MongoDB database to store the Ops Manager's operational data. The [application database](https://www.mongodb.com/docs/ops-manager/current/reference/glossary.md#std-term-application-database) runs as a [replica set](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-replica-set) to ensure redundancy and high availability. This replica set hosts *only* Ops Manager data. Before installing Ops Manager, you must [provision the application database](https://www.mongodb.com/docs/ops-manager/current/tutorial/prepare-backing-mongodb-instances.md). This database contains [Ops Manager Application](https://www.mongodb.com/docs/ops-manager/current/core/system-overview.md#std-label-application) metadata: - Monitoring data collected from the MongoDB Agents. - Metadata for Ops Manager users, projects, hosts, monitoring data, and backup state. For topology and specifications, see [Ops Manager Application Database Hardware Requirements.](https://www.mongodb.com/docs/ops-manager/current/core/requirements.md#std-label-mms-application-database-specifications) ### Snapshot Storage Ops Manager creates snapshots of deployments to back up your databases. You can have Ops Manager store these snapshots in [snapshot stores](https://www.mongodb.com/docs/ops-manager/current/reference/glossary/#std-term-snapshot-store). Snapshot stores can be local databases, local file systems, or cloud-based data stores. There can be more than one snapshot store per project. Ops Manager writes the recent history of the deployment database to a separate database regardless of where the snapshots are written. Snapshot storage include two components: #### Snapshot Stores Snapshots can be written to one of three target storage systems: | System | Storage Method | Learn More | | --- | --- | --- | | [blockstore](https://www.mongodb.com/docs/ops-manager/current/reference/glossary.md#std-term-backup-blockstore-database) | A MongoDB database stored in a local host. | [Manage Blockstore Snapshot Storage](https://www.mongodb.com/docs/ops-manager/current/tutorial/manage-blockstore-storage.md) | | [S3 snapshot store](https://www.mongodb.com/docs/ops-manager/current/reference/glossary/#std-term-S3-snapshot-store) | A cloud data store in S3-compatible storage. | [Manage S3-Compatible Snapshot Storage](https://www.mongodb.com/docs/ops-manager/current/tutorial/manage-s3-blockstore-storage.md) | | [file system store](https://www.mongodb.com/docs/ops-manager/current/reference/glossary/#std-term-File-System-Store) | A local file system in the directory of your choosing. | [Manage File System Snapshot Storage](https://www.mongodb.com/docs/ops-manager/current/tutorial/manage-filestore-storage.md) | #### Oplog Store The [Oplog Store](https://www.mongodb.com/docs/ops-manager/current/reference/glossary/#std-term-Oplog-Store-Database) retains the [oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog) entries that the [Backup Daemon](https://www.mongodb.com/docs/ops-manager/current/reference/glossary/#std-term-backup-daemon) applies to its local copies of your backed-up deployments. **See also:** To learn about the requirements and procedures for Oplog Stores, see [Manage Oplog Storage.](https://www.mongodb.com/docs/ops-manager/current/tutorial/manage-oplog-storage.md)