Navigation
This version of the documentation is archived and no longer supported. To learn how to upgrade your version of MongoDB Ops Manager, refer to the upgrade documentation.
You were redirected from a different version of the documentation. Click here to go back.

Backup Process

Backups depend upon which version of MongoDB your database is compatible. This Feature Compatibility Version ranges from the current version to one version earlier. For MongoDB 4.2, the FCV can be 4.0 or 4.2.

Ops Manager makes two changes when you upgrade your database from FCV 4.0 to FCV 4.2.

  1. Ops Manager reclaims the disk space that stored the head directory.
  2. Ops Manager deletes the head directory after the backup job registers the new FCV from the source replica set.

The backup process takes a snapshot of the data directory at its scheduled snapshot intervals. This process copies the data files in a MongoDB deployment, sending them over the network via Ops Manager to your existing snapshot storage. Your deployment can still handle read and write operations during the copying process.

The backup process works in this manner regardless of how snapshots are stored.

Note

With the new Backup process, there are no longer initial syncs. As a result of not having initial syncs, Ops Manager can support a wider array of customers such as those heavily using renameCollection.

Backup Definition and Operational States

Each backup is defined as a job. Each job defines how much and how often data is backed up. Backup jobs are defined on a per-project basis.

Operational States

The following table lists the states of a backup job:

State Retain Old Snapshots Create New Snapshots
Active Yes Yes
Stopped Yes No
Inactive No No

Change Operational States

Once backup jobs are active for a project, they run without further intervention until they are stopped or terminated. The operator can change the state of a backup in the following ways:

Initial State Desired State Method
Inactive Active Click Start.
Active Stopped Click Stop.
Stopped Active Click Restart.
Stopped Inactive

Click Terminate.

Warning

Terminate deletes all retained backups.

Backup Process Flows

Once created, a backup job goes through the following process flow:

Diagram showing the flow of data for Ops Manager's backup components when using snapshot storage.
  1. When the cluster is ready for its scheduled snapshot, it determines an optimal available node to take the snapshot. In most cases, the mongod determines lowest priority secondary member as the preferred snapshot node. Other metrics can factor into determining the preferred node, such as how current the secondary is with the primary and the previously chosen snapshot’s member.

  2. Once the mongod process determines the origin node for the snapshot, the backup process opens a $backupCursor on the targeted node.

    The $backupCursor, a storage engine layer mechanism, allows the database files in storage to be copied in a consistent state while still accepting writes.

  3. The MongoDB Agent Backup function copies and processes these data files.

  4. The MongoDB Agent Backup function sends the data files to Ops Manager.

  5. The backup process collects and transfers these files to the snapshot store that you choose to store your backup. Depending upon which snapshot store you chose to store your snapshot, a snapshot can be written out as:

    1. Blocks to a blockstore. Binary chunks written to a MongoDB database on the Ops Manager host.
    2. Blocks to an AWS S3 bucket. The metadata for those blocks is written to a MongoDB database on the Ops Manager host.
    3. Snapshot files to a file system store.

Note

To learn more about the characteristics of each storage method, see Backup Configuration Options.

Was this page helpful?