For AI agents: a documentation index is available at https://www.mongodb.com/docs/llms.txt — markdown versions of all pages are available by appending .md to any URL path.

Back Up the Ops Manager Application Database

The Application Database stores your Ops Manager settings, operation history, and backup metadata. When you deploy the Application Database as an external Application Database, the Kubernetes Operator manages it as a standard MongoDB custom resource, which means that Ops Manager can back it up and restore it like any other MongoDB deployment that the Kubernetes Operator manages.

To deploy an external Application Database, see the following procedures:

An Ops Manager deployment with an internally managed Application Database stores the Application Database inside the Ops Manager custom resource, where standard backup tooling can't reach it. If Ops Manager itself fails, you can lose control of the deployments that it manages.

Backing up an external Application Database addresses the following needs:

  • Disaster recovery. Restore the Application Database after data loss, data corruption, or a failed configuration change.

  • Operational safety net. Roll back an erroneous bulk write to the moment before it happened.

  • Lower recovery objectives. Continuous oplog capture can lower the recovery point objective by preserving changes between snapshots.

Ops Manager keeps a copy of the Application Database data and a continuous stream of oplog entries, which lets you do the following:

  • Restore a full snapshot of the Application Database to a new or existing deployment.

  • Restore the Application Database to any point in time between snapshots by replaying the oplog to a timestamp that you choose.

  • Query a backup snapshot without restoring it. To learn more, see Configure Queryable Backups for Ops Manager Resources.

  • Meet retention and compliance requirements, optionally with immutable snapshots.

An external Application Database deployment uses the following resources:

Resource
Description

Management Ops Manager

An Ops Manager resource with its own internally managed Application Database. The management Ops Manager instance doesn't manage your databases. It manages the project that contains the external Application Database, and it acts as the recovery engine if you lose the primary Ops Manager instance. Deploy it in a separate failure domain, such as a different availability zone.

External Application Database

A MongoDB or MongoDBMultiCluster resource with spec.role set to AppDB. To learn more, see MongoDB Database Resource Specification and Multi-Kubernetes-Cluster Resource Specification. Its name must be <primary-om-name>-db. The management Ops Manager instance manages this resource as a project, so you can enable backup on it like any other MongoDB resource.

Primary Ops Manager

The Ops Manager resource that manages your databases. It omits spec.applicationDatabase and references the external Application Database with spec.externalApplicationDatabaseRef.

Because a new Ops Manager instance can't start without an Application Database, and a MongoDB resource with spec.role set to AppDB can't reconcile without an available Ops Manager instance, the management Ops Manager instance is a prerequisite for an external Application Database. Deploy it before you deploy the external Application Database.

If you lose the primary Ops Manager instance, you use the management Ops Manager instance to restore the external Application Database, then recreate the primary Ops Manager instance against the restored Application Database, then restore your MongoDB workloads.

You can deploy the external Application Database as a MongoDBMultiCluster resource to spread the Application Database members across multiple Kubernetes clusters. The Kubernetes Operator creates one Application Database StatefulSet per member cluster, named <primary-om-name>-db-<cluster-index>, and the primary Ops Manager resource references it with spec.externalApplicationDatabaseRef set to kind MongoDBMultiCluster.

A multi-cluster external Application Database requires TLS encryption and cross-cluster networking between the member clusters. You can provide this networking with a service mesh, such as Istio, or without a service mesh. For a deployment without a service mesh, see Multi-Cluster Ops Manager Without a Service Mesh. To learn more, see Deploy a Multi-Cluster External Application Database.

Ops Manager stores backup metadata in the Application Database, and both the Ops Manager Application and the Backup Daemon connect to the Application Database. When you reference an external Application Database with spec.externalApplicationDatabaseRef, the Kubernetes Operator handles this connection for you:

  • The Kubernetes Operator resolves the TLS configuration and CA of the referenced MongoDB resource and applies it to both the Ops Manager StatefulSet and the Backup Daemon StatefulSet. The Backup Daemon trusts a TLS-enabled external Application Database the same way it trusts an internally managed one.

  • The Backup Daemon connects using the same connection string that the Kubernetes Operator computes for the Ops Manager Application.

Enabling backup doesn't change. You set spec.backup.enabled on the primary Ops Manager resource, as you would for an internally managed Application Database. The only difference is where the Application Database runs.

To back up the external Application Database itself, enable backup on the MongoDB resource that represents it, in the project that the management Ops Manager instance manages. To learn more, see Configure MongoDB Database Backups.

During a migration between an internally managed Application Database and an external Application Database, the Kubernetes Operator sets an annotation on the Application Database StatefulSet to record that the StatefulSet is ready to change owners. The Kubernetes Operator sets and reads these annotations. Don't set them yourself.

In a multi-cluster deployment, the Kubernetes Operator applies these annotations to the Application Database StatefulSet in each member cluster. The Kubernetes Operator tracks ownership of each member-cluster StatefulSet with the mongodbmulticluster label instead of an owner reference. A StatefulSet in a member cluster can't carry an owner reference to a resource in the central cluster.

Annotation
Description

mongodb.com/appdb-migration-ready

The Ops Manager resource released the StatefulSet so that the MongoDB resource can take ownership of it. The Kubernetes Operator sets this annotation when you migrate from an internally managed Application Database to an external Application Database. To learn more, see Migrate an Application Database to an External Deployment.

mongodb.com/appdb-reverse-migration-ready

The MongoDB resource released the StatefulSet so that the Ops Manager resource can reclaim it. The Kubernetes Operator sets this annotation when you return an external Application Database to internal management. To learn more, see Return an External Application Database to Ops Manager.

Before you back up an external Application Database, complete the following tasks:

External Application Database backup has the following limitations:

  • A MongoDB resource with spec.role set to AppDB must use a single-cluster topology. To spread the external Application Database across multiple Kubernetes clusters, use a MongoDBMultiCluster resource, as described in Deploy a Multi-Cluster External Application Database.

  • This feature doesn't back up or restore Ops Manager state other than the Application Database itself.

  • This feature doesn't change how you back up or restore the MongoDB deployments that you manage with Ops Manager.

  • The Kubernetes Operator doesn't support automationConfig overrides for an external Application Database, because the MongoDB resource has no equivalent setting.

  • The Kubernetes Operator doesn't support spec.applicationDatabase.passwordSecretKeyRef during migration to an external Application Database. The Kubernetes Operator generates a new password and rotates any password that you provided.

  • When you reference an existing MongoDB deployment as an external Application Database, you take on responsibility for the day-to-day management of that deployment. The Kubernetes Operator provides no tool that reconciles the MongoDB resource configuration with the internally managed Application Database configuration. You must specify that configuration yourself.