- Administer Ops Manager >
- Back Up Ops Manager
Back Up Ops Manager¶
Deploying the Ops Manager Backup Blockstore and Application databases as replica sets is key to protect the databases from failure.
Ensure you configure and deploy your replica sets for failover and redundancy.
See also
To learn more about replica set architecture:
Beyond using MongoDB’s replication capabilities, you can create backups for the Backup Blockstore database and Application database, both for longterm storage of snapshots, and for backing up Ops Manager for disaster recovery purposes.
To restore Ops Manager, you only need backups of the Application database and the Backup Blockstore database. Ops Manager’s other components are stateless: you can rebuild them from the installation package if need be.
Important
Your Backup installation cannot back up Ops Manager. If you wish to use Ops Manager to back up Ops Manager, you will need two Ops Manager installations: one to back up your MongoDB deployment, and another to back up your Ops Manager databases.
Back Up with the Public API¶
The Ops Manager Public API allows you to programmatically restore snapshots on your desired schedule, and store them offline. Ideally, you should save the backups to a tape drive, appending the new snapshots daily until the drive is full, and then store the drive offsite.
Programmatically restoring snapshots has the same impact on a snapshot as a typical restore.
See the API documentation for how to restore jobs using this method.
This method backs up the snapshots only: you cannot use the backups to restore Ops Manager in the event that a Blockstore database is lost.
Shut Down and Back Up Ops Manager¶
To perform a full backup of all snapshots contained in Ops Manager, including the point-in-time restores:
- Ubuntu/Debian
- RHEL/CentOS/SLES/AMZ
- Linux
Use this procedure to back up the Ops Manager Application on hosts
installed using deb
packages:
Shut down your Ops Manager instance.¶
Issue the following command to stop the Ops Manager Application:
This shuts down the Backup Daemon and the head database that it uses. This prevents any further snapshots from being created.
Back up the Ops Manager configuration files.¶
Back up the configuration directory and gen.key
file. By default,
Ops Manager stores these in the following locations:
/opt/mongodb/mms/conf
/etc/mongodb-mms/gen.key
Warning
If you lose the gen.key
file, your Ops Manager instance can’t
connect to the application or backup databases.
Shut down your Ops Manager application database.¶
Locate the connection strings for the application database from
mongo.mongoUri
in theconf-mms.properties
file.Log in to the application database using
mongo
.Invoke the
db.shutdownServer()
command:
Shut down your Ops Manager backup databases.¶
For each backup database in your Ops Manager installation including:
- blockstores
- Oplog Stores
- S3 Snapshot Store metadata databases
Repeat the following steps:
Locate the connection strings for the backup databases from the Snapshot Storage.
Log in to each database using
mongo
.Invoke the
db.shutdownServer()
command:
Back up the supporting file systems.¶
While they are offline, use your preferred method to back up the file systems that store:
- The application
- Any backup databases
- Any File System Stores
Use this procedure to back up the Ops Manager Application on hosts
installed using rpm
packages:
Shut down your Ops Manager instance.¶
Issue the following command to stop the Ops Manager Application:
This shuts down the Backup Daemon and the head database that it uses. This prevents any further snapshots from being created.
Back up the Ops Manager configuration files.¶
Back up the configuration directory and gen.key
file. By default,
Ops Manager stores these in the following locations:
/opt/mongodb/mms/conf
/etc/mongodb-mms/gen.key
Warning
If you lose the gen.key
file, your Ops Manager instance can’t
connect to the application or backup databases.
Shut down your Ops Manager application database.¶
Locate the connection strings for the application database from
mongo.mongoUri
in theconf-mms.properties
file.Log in to the application database using
mongo
.Invoke the
db.shutdownServer()
command:
Shut down your Ops Manager backup databases.¶
For each backup database in your Ops Manager installation including:
- blockstores
- Oplog Stores
- S3 Snapshot Store metadata databases
Repeat the following steps:
Locate the connection strings for the backup databases from the Snapshot Storage.
Log in to each database using
mongo
.Invoke the
db.shutdownServer()
command:
Back up the supporting file systems.¶
While they are offline, use your preferred method to back up the file systems that store:
- The application
- Any backup databases
- Any File System Stores
Use this procedure to back up Linux systems that don’t use
deb
or rpm
packages.
Shut down your Ops Manager instance.¶
Issue the following command to stop the Ops Manager Application:
This shuts down the Backup Daemon and the head database that it uses. This prevents any further snapshots from being created.
Back up the Ops Manager configuration files.¶
Back up the configuration directory and gen.key
file. By default,
Ops Manager stores these in the following locations:
/opt/mongodb/mms/conf
/etc/mongodb-mms/gen.key
Warning
If you lose the gen.key
file, your Ops Manager instance can’t
connect to the application or backup databases.
Shut down your Ops Manager application database.¶
Locate the connection strings for the application database from
mongo.mongoUri
in theconf-mms.properties
file.Log in to the application database using
mongo
.Invoke the
db.shutdownServer()
command:
Shut down your Ops Manager backup databases.¶
For each backup database in your Ops Manager installation including:
- blockstores
- Oplog Stores
- S3 Snapshot Store metadata databases
Repeat the following steps:
Locate the connection strings for the backup databases from the Snapshot Storage.
Log in to each database using
mongo
.Invoke the
db.shutdownServer()
command:
Back up the supporting file systems.¶
While they are offline, use your preferred method to back up the file systems that store:
- The application
- Any backup databases
- Any File System Stores
While this procedure makes all of Ops Manager’s backup snapshots and the PIT restores available, it involves significant downtime, During the shutdown, Ops Manager, monitoring, and automation are unavailable.
As a result, if one of your MongoDB instances fails:
- You may lose the data that Ops Manager didn’t back up prior to shutdown.
- You can’t be alerted of the loss of data.