- Administration >
- 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 Replica Set High Availability and Replica Set Deployment Architectures for 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 packages 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 provides the ability 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 the Backup Blockstore database as a typical restore.
You can then restore your MongoDB instance from the stored snapshots.
This method backs up the snapshots only: you cannot use the backups to restore Ops Manager in the event that the Blockstore is lost.
Shut Down and Back Up¶
You can perform a full backup of all snapshots contained in Ops Manager, as well as the point-in-time restores that Backup stores by shutting down Ops Manager and all of the hosts monitored and backed up by Ops Manager, and then backing up their file systems while they’re offline.
The ‘Shut Down and Back Up’ approach has the advantage of providing all of Ops Manager’s backup snap shots as well as the point-in-time restores that it stores. However, the process involves significant downtime and during the shut down, Ops Manager is completely unavailable. As such, if a failure occurs in one of your MongoDB instances, you may lose the data that was not backed up by Ops Manager prior to the shutdown.
Online Backup¶
Online backup is the riskiest option, as it involves backing up the databases while Ops Manager is running. If done correctly, this provides you with all of the backup snapshots contained in Ops Manager, as well as the point-in-time restores for the period leading up to the backup.
However, the process is complex and there is high potential for errors.
To perform the online backup for databases using the MMAPv1 storage engine,
you must run fsyncLock on each
mongod process that is part of the Application and Backup
Blockstore replica sets in the correct order, back up the underlying
file system, and then call fsyncUnlock. If you forget to call
fsyncUnlock on a mongod instance, you risk significant
long-term problems and failures.
Note
The fsyncLock command is not appropriate for databases that use
the WiredTiger storage engine. See db.fsyncLock() in the MongoDB manual.