Resync a Backup
On this page
- OAuth 2.0 authentication for programmatic access to Cloud Manager is available as a Preview feature.
- The feature and the corresponding documentation might change at any time during the Preview period. To use OAuth 2.0 authentication, create a service account to use in your requests to the Cloud Manager Public API.
Note
You don't need to resync MongoDB databases that run with
FCV 4.2 or later.
When a backup becomes out of sync with the MongoDB deployment, Cloud Manager
produces a Backup requires a resync alert. If you
receive this alert, you must resync the backup for the specified
MongoDB instance.
The following scenarios trigger a Backup requires a resync alert:
- The Oplog has rolled over
- This is the most common case for the
Backup requires a resyncalert. It occurs whenever the Backup's tailing cursor cannot keep up with the deployment's oplog. This is similar to when a secondary falls too far behind the primary in a replica set. Without a resync, the backups will not catch up. - Unsafe applyOps
- This occurs when a document that Backup does not have a copy of is indicated.
- Data corruption or other illegal instruction
- This typically causes replication, and therefore the backup job, to break. When the daemon sees the broken job, it requests a resync.
During the resync, data is read from a secondary in each replica set and Cloud Manager does not produce any new snapshots.
Note
For production deployments with FCV 4.0 or earlier, you
should resync all backups annually.
Important
Cloud Manager does not attempt to automatically recover from conditions that
caused the Backup requires a resync alert. This
alert means there is not enough data to complete a restore. There is
no way to automatically recover from not having enough data from the
snapshots and the oplog. Resyncing the backup is the best option.
Considerations
As of FCV 4.2, deployments are backed up with WiredTiger checkpoints using backup cursors. Applications can continue read and write operations on the database while WiredTiger takes the snapshot.
For production deployments with FCV 4.0 or earlier, to
avoid the need for resyncs, ensure the Backup oplog does not fall
behind the deployment's oplog. This requires that:
Adequate machine resources are provisioned for the agent.
You restart the Cloud Manager agents in a timely manner following maintenance or other downtime.
To provide a buffer for maintenance and for occasional activity bursts, ensure that the oplog on the primary is large enough to contain at least 24 hours of activity.
You should resync the head database after you create an index in a rolling fashion to ensure that the head database takes the new index into account.
Procedure
In MongoDB Cloud Manager, go to the Continuous Backup page for your project.
If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.
If it's not already displayed, select your desired project from the Projects menu in the navigation bar.
Click Continuous Backup in the sidebar.
The Continuous Backup page displays.