Backup Process
Backups depend upon which version of MongoDB your database is
compatible. For
MongoDB 4.4, the FCV can be 4.2 or 4.4.
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 |
Misconfigured | Yes | No |
Note
The Misconfigured state applies only to Regional Backup.
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
mongoddetermines 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
mongodprocess determines the origin node for the snapshot, the backup process opens a$backupCursoron 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.
Regional Backup
You can assign backup jobs to Deployment Regions to promote data isolation. When you assign a backup job to a deployment region, Ops Manager writes all snapshots, oplogs, and sync data that the job generates to the relevant storage configured for that region. Regional backup is available for replica sets and sharded clusters. To enable regional backup for a sharded cluster, you must assign deployment regions and initiate backup jobs for each shard separately.
To determine whether regional backup is enabled in your deployment, you can check for the following in the Continuous Backup dashboard.
Backup Region on the top right corner displays the group's deployment region by default and if the project is enabled for regional backup, it displays the legend Multi-Region.
Regional Backup column displays in the dashboard.