Navigation
You were redirected from a different version of the documentation. Click here to go back.

Back Up Ops Manager

On this page

    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:

    Use this procedure to back up the Ops Manager Application on hosts installed using deb packages:

    1

    Shut down your Ops Manager instance.

    Issue the following command to stop the Ops Manager Application:

    copy 
    sudo service mongodb-mms stop

    This shuts down the Backup Daemon and the head database that it uses. This prevents any further snapshots from being created.

    2

    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.

    3

    Shut down your Ops Manager application database.

    1. Locate the connection strings for the application database from mongo.mongoUri in the conf-mms.properties file.

    2. Log in to the application database using mongo.

    3. Invoke the db.shutdownServer() command:

      copy 
      db.getSiblingDB('admin').shutdownServer({});
    4

    Shut down your Ops Manager backup databases.

    For each backup database in your Ops Manager installation including:

    Repeat the following steps:

    1. Locate the connection strings for the backup databases from the Snapshot Storage.

    2. Log in to each database using mongo.

    3. Invoke the db.shutdownServer() command:

      copy 
      db.getSiblingDB('admin').shutdownServer({});
    5

    Back up the supporting file systems.

    While they are offline, use your preferred method to back up the file systems that store:

    Use this procedure to back up the Ops Manager Application on hosts installed using rpm packages:

    1

    Shut down your Ops Manager instance.

    Issue the following command to stop the Ops Manager Application:

    copy 
    sudo service mongodb-mms stop

    This shuts down the Backup Daemon and the head database that it uses. This prevents any further snapshots from being created.

    2

    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.

    3

    Shut down your Ops Manager application database.

    1. Locate the connection strings for the application database from mongo.mongoUri in the conf-mms.properties file.

    2. Log in to the application database using mongo.

    3. Invoke the db.shutdownServer() command:

      copy 
      db.getSiblingDB('admin').shutdownServer({});
    4

    Shut down your Ops Manager backup databases.

    For each backup database in your Ops Manager installation including:

    Repeat the following steps:

    1. Locate the connection strings for the backup databases from the Snapshot Storage.

    2. Log in to each database using mongo.

    3. Invoke the db.shutdownServer() command:

      copy 
      db.getSiblingDB('admin').shutdownServer({});
    5

    Back up the supporting file systems.

    While they are offline, use your preferred method to back up the file systems that store:

    Use this procedure to back up Linux systems that don’t use deb or rpm packages.

    1

    Shut down your Ops Manager instance.

    Issue the following command to stop the Ops Manager Application:

    copy 
    sudo service mongodb-mms stop

    This shuts down the Backup Daemon and the head database that it uses. This prevents any further snapshots from being created.

    2

    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.

    3

    Shut down your Ops Manager application database.

    1. Locate the connection strings for the application database from mongo.mongoUri in the conf-mms.properties file.

    2. Log in to the application database using mongo.

    3. Invoke the db.shutdownServer() command:

      copy 
      db.getSiblingDB('admin').shutdownServer({});
    4

    Shut down your Ops Manager backup databases.

    For each backup database in your Ops Manager installation including:

    Repeat the following steps:

    1. Locate the connection strings for the backup databases from the Snapshot Storage.

    2. Log in to each database using mongo.

    3. Invoke the db.shutdownServer() command:

      copy 
      db.getSiblingDB('admin').shutdownServer({});
    5

    Back up the supporting file systems.

    While they are offline, use your preferred method to back up the file systems that store:

    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.

    See also

    Back up and Restore with Filesystem Snapshots.

    © MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.