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.

Resync a Backup

On this page

Note

You don’t need to resync MongoDB databases that run with an FCV of 4.2.

When a backup becomes out of sync with the MongoDB deployment, Ops 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 resync alert. 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 Ops Manager does not produce any new snapshots.

Note

For production deployments, you should resync all backups annually.

Important

Ops 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

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 Ops 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.

See also

For more information on the Backup oplog, see the FAQ: Backup and Restore.

Procedure

1

Click Continuous Backup, then the Overview tab.

2

On the line listing the process, click the ellipsis icon and click Resync.

3

Click the Resync button.

If prompted for an authentication code, enter the code and click Verify. Click Resync again.

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.