- Back Up and Restore Deployments >
- Back up MongoDB Deployments >
- Backup Process
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
.
- FCV 4.2 or later
- FCV 4.0 or earlier
Ops Manager makes two changes when you upgrade your database from FCV
4.0 to FCV 4.2.
- Ops Manager reclaims the disk space that stored the head directory.
- 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:
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.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.The MongoDB Agent Backup function copies and processes these data files.
The MongoDB Agent Backup function sends the data files to Ops Manager.
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:
- Blocks to a blockstore. Binary chunks written to a MongoDB database on the Ops Manager host.
- Blocks to an AWS S3 bucket. The metadata for those blocks is written to a MongoDB database on the Ops Manager host.
- Snapshot files to a file system store.
Note
To learn more about the characteristics of each storage method, see Backup Configuration Options.