<!-- llms-explorer concept facts · https://llms-explorer.com/tree/ops-manager-architecture/ · pack 2026-10-23 · ~1691 tokens -->

# Ops Manager Architecture

> Source-anchored research for Ops Manager Architecture. Run status: COMPLETED.

Parent: [MongoDB Ops Manager and Cloud Manager](https://llms-explorer.com/tree/mongodb-ops-manager-and-cloud-manager/) · 4 facets · 18 facts · page: https://llms-explorer.com/tree/ops-manager-architecture/

## Structure and components

- Ops Manager separates HTTP management services, a dedicated MongoDB Application Database, and optional backup services and storage; the Kubernetes custom resource represents the application, Application Database, and Backup Daemon as distinct components. (high confidence) — [source](https://www.mongodb.com/docs/ops-manager/current/core/system-overview.md)
- In Kubernetes, the MongoDBOpsManager resource represents the management service, its backing database, and the optional Backup Daemon. The operator starts the backing database first, then the management service, then backup components when enabled. (low confidence) — [source](https://www.mongodb.com/docs/kubernetes/current/tutorial/arch-om-resources.md)

## How it works

- Management HTTP services are stateless: multiple application instances can serve users and agents when they share the same configuration and Application Database. Kubernetes deploys application replicas as separate Pods managed by StatefulSets. (high confidence) — [source](https://www.mongodb.com/docs/ops-manager/current/core/system-overview.md)
- Agents reconcile MongoDB processes against desired deployment configuration. Nutanix's implementation illustrates this control loop by submitting an updated Automation Config and waiting for agent convergence when adding a shard. (medium confidence) — [source](https://www.kinekube.com/blog/provisioning-mongodb-with-ops-manager/)

## Comparisons and alternatives

- Third-party backup integration adds an external orchestrator rather than replacing Ops Manager database coordination. Nutanix NDB drives infrastructure and backup workflows through Ops Manager REST APIs; NetBackup requires protected clusters to be marked Third Party Managed in Ops Manager. (medium confidence) (verified as of 2026-04-07) — [source](https://www.nutanix.com/blog/onboarding-mongodb-ops-manager-in-nutanix-ndb)
- Ops Manager separates its management services from a dedicated MongoDB replica set holding operational state; snapshot and oplog storage add distinct backup responsibilities rather than replacing that operational database. (high confidence) — [source](https://www.mongodb.com/docs/ops-manager/current/core/system-overview.md)
- Direct to S3 Backup requires outbound DNS and HTTPS access to the object endpoint from backup agent hosts. Agents use pre-signed URLs rather than receiving the snapshot store's S3 credentials. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/ops-manager/current/core/backup-direct-to-s3.md)

## Facts and statements

- The Application Database holds monitoring data and management metadata, including backup state. It is a dedicated MongoDB replica set for Ops Manager data; Kubernetes supplies persistent volumes and agents that start its mongod members. (high confidence) — [source](https://www.mongodb.com/docs/ops-manager/current/core/system-overview.md)
- Backup Daemons perform maintenance such as grooming, filesystem snapshot work, and queryable restores. Their state and job queues reside in the Application Database; client applications do not communicate directly with the daemon. (low confidence) — [source](https://www.mongodb.com/docs/ops-manager/current/core/system-overview.md)
- Snapshot storage and oplog retention are distinct architectural responsibilities. Snapshot targets include a MongoDB blockstore, S3-compatible storage, and a filesystem store; S3 snapshot blocks still require MongoDB metadata storage. (high confidence) — [source](https://www.mongodb.com/docs/ops-manager/current/core/system-overview.md)
- Modern snapshot capture uses an agent colocated with a data-bearing MongoDB server to open a storage-engine backup cursor and copy consistent files while writes continue. Ops Manager 4.2.0 introduced FCV 4.2 backup without the legacy head-database requirement; old head-database diagrams should not be generalized to this path. (high confidence) — [source](https://www.mongodb.com/docs/ops-manager/current/core/backup-overview.md)
- Kubernetes reconciliation brings up the Application Database before the management application, then starts the optional Backup Daemon and configures backup through Ops Manager APIs. The application and daemon have separate StatefulSets. (low confidence) — [source](https://www.mongodb.com/docs/kubernetes/current/tutorial/arch-om-resources.md)
- NetBackup 11.1 documents cluster discovery, policy-driven backups, full restore, point-in-time restore, and restore to a different cluster in its Ops Manager integration. (low confidence) (verified as of 2025-11-25) — [source](https://www.veritas.com/content/support/en_US/doc/167996996-170849162-1)
- MCK 1.12.0 release notes describe an externally managed AppDB referenced through spec.externalApplicationDatabaseRef. They require a separate management Ops Manager for complete AppDB disaster recovery and explicitly exclude multi-cluster AppDB support from that initial release. (low confidence) (verified as of 2026-09-08) — [source](https://github.com/mongodb/mongodb-kubernetes/releases)
- Kubernetes deployment order and backup configuration are separate concerns: the operator invokes Ops Manager APIs to reconcile configured backup stores after deploying the Backup Daemon. (low confidence) — [source](https://www.mongodb.com/docs/kubernetes/current/tutorial/arch-om-resources.md)
- Ops Manager 8.0.27, released September 30, 2026, added Direct to S3 Backup: eligible agents upload snapshot blocks using pre-signed URLs, bypassing the management server's payload proxy while Ops Manager coordinates metadata. (high confidence) (verified as of 2026-09-30) — [source](https://www.mongodb.com/docs/ops-manager/current/core/backup-direct-to-s3.md)
- Direct to S3 Backup changes only the snapshot-block path. Oplog data continues through the configured oplog store; agents below the minimum supported version use the standard snapshot path until upgraded. (low confidence) (verified as of 2026-10-14) — [source](https://www.mongodb.com/docs/ops-manager/current/core/backup-direct-to-s3.md)
- Nutanix's integration treats MongoDB topology changes and backup topology as separately coordinated state: after updating Automation Config, it enables backup agents and refreshes backup topology before resuming protection. (low confidence) (verified as of 2026-07-28) — [source](https://www.nutanix.com/blog/scaling-mongodb-sharded-clusters-with-nutanix-ndb)
