Backup and restore of Ops Manager with a secondary Ops Manager instance is in Preview. This feature and its documentation might change at any time during the preview period.
This guide shows you how to configure a secondary Ops Manager to back up a primary Ops Manager and its backing databases. For an overview of this pattern, see Back Up and Restore Ops Manager Using a Secondary Instance.
Considerations
Isolate This Backup Configuration
Keep this backup configuration separate from the backups that the primary Ops Manager takes of your MongoDB deployments. Use a dedicated project on the secondary Ops Manager for the primary Ops Manager's backing databases. This separation prevents confusion between Ops Manager disaster recovery backups and your application backups.
Back Up All Backing Databases
You must back up the primary Ops Manager's application database. Back up the snapshot metadata store and the oplog metadata store as well. When you back up all three backing databases, you can restore them to a single consistent point in time.
Prerequisites
Before you configure the secondary Ops Manager, complete the following prerequisites.
Secondary Ops Manager Instance
Deploy a secondary Ops Manager in a separate failure domain from the primary Ops Manager. You can use a fresh Ops Manager installation that runs the same version as the primary Ops Manager or a later version.
Deploy the secondary Ops Manager's own application database as a replica set for high availability.
Enable and configure a Backup Daemon on the secondary Ops Manager with an S3-compatible storage blockstore for the primary Ops Manager's application database snapshots.
Primary Ops Manager Backing Databases
Run the primary Ops Manager's application database as a multi-member replica set (for example, a three-member replica set) for automatic failover. Backup supports replica sets and sharded clusters. If you must back up an existing standalone application database, convert it to a replica set first. Use a single-member replica set only as a transitional step toward a multi-member topology.
Run the application database on MongoDB Enterprise.
To test the backup and restore path end to end, ensure the primary Ops Manager has at least one project with a backup-enabled managed cluster.
Network and Security
Allow the secondary Ops Manager application servers to reach the primary Ops Manager's backing database hosts on the MongoDB Agent port.
Allow the primary Ops Manager's backing database hosts to reach the secondary Ops Manager on the secondary Ops Manager application port.
Enable TLS or equivalent transport encryption between the primary and secondary Ops Manager instances. The backup traffic carries the primary Ops Manager's application configuration, which includes credentials and other sensitive data.
Confirm that you can authenticate to the primary Ops Manager's backing databases. To learn more, see Configure the Connections to the Application Database.
Preserve Per-Host State
Before a disaster occurs, preserve the following files on each primary Ops Manager host. These files are not part of the application database backup and must be retained separately:
Item | Location | Description |
|---|---|---|
Encryption key |
| Encrypts the application database contents. Must match the key used for the original installation, or the primary Ops Manager can't decrypt the restored application database on startup. |
Ops Manager configuration |
| Stores database URIs, blockstore configuration, license keys, and TLS certificates. Without it, you must reconfigure the primary Ops Manager by hand. |
Agent configuration |
| Stores the |
Important
If the gen.key file is missing or doesn't match the restored
application database, the primary Ops Manager fails its startup
preflight check with an error that gen.key doesn't match the
key already used for this Ops Manager installation. Keep gen.key
in your disaster recovery backup alongside the application database
data.
Procedure
Add the application database to the secondary Ops Manager
On the secondary Ops Manager, add the primary Ops Manager's application database as an existing deployment:
Create or select a dedicated project for the primary Ops Manager's backing databases.
Click Deployment, Add Existing MongoDB Deployment, then add the application database replica set. To learn more, see Add Existing MongoDB Processes to Ops Manager.
Install the MongoDB Agent on each application database host and register it with the secondary Ops Manager using the secondary Ops Manager project's
mmsGroupIdandmmsApiKey. To learn more, see Install the MongoDB Agent to Manage Deployments.Confirm that all application database members show as healthy in the secondary Ops Manager before you continue.
Enable backup for the application database
In the secondary Ops Manager, enable backup for the primary Ops Manager's application database:
From the deployment view, click the menu, then click Enable Backup.
Confirm that the Backup Daemon is running and a blockstore is configured on the secondary Ops Manager.
Set the snapshot schedule, retention policy, and storage target.
Wait for the first snapshot to complete and for a continuous point-in-time recovery window to appear. This confirms that the backup is healthy.
To learn more about backup configuration, see Back up a Deployment.
Back up the metadata stores
Also back up the primary Ops Manager's snapshot metadata store and oplog metadata store:
Add each replica set to the secondary Ops Manager the same way you added the application database.
Enable backup for each.
Backing up all three backing databases lets you restore them to a single consistent point in time during recovery.
Note
Restoration Mode is enabled by default in Ops Manager 8.0.24 and
later. To disable it, set the custom variable
mms.featureFlag.automation.restorationMode to disabled
under Admin, General,
Ops Manager Config, Custom Variables.
The change takes effect on the next MongoDB Agent poll, without
a restart.
After you configure this pattern, validate the restore path regularly. To restore the primary Ops Manager in a disaster recovery event, see Restore Ops Manager from a Secondary Ops Manager.