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 Preparations

Overview

Before backing up your cluster or replica set, decide how to back up the data and what data to back up. This page describes items you must consider before starting a backup.

For an overview of how Backup works, see Backup.

Snapshot Frequency and Retention Policy

By default, Ops Manager takes a base snapshot of your data every 6 hours. If desired, administrators can change the frequency of base snapshots to 8, 12, or 24 hours. Ops Manager creates snapshots automatically on a schedule. You cannot take snapshots on demand.

Ops Manager retains snapshots for the time periods listed in the following table. If you terminate a backup, Ops Manager immediately deletes the backup’s snapshots.

Snapshot Default Retention Policy Maximum Retention Setting
Base snapshot. 2 days 5 days.
Daily snapshot 1 week 1 year
Weekly snapshot 1 month 1 year
Monthly snapshot 1 year 3 years.

You can change a backed-up deployment’s schedule through its Edit Snapshot Schedule menu option, available through the Backup tab. Administrators can change snapshot frequency and retention through the snapshotSchedule resource in the API. If you change the schedule to save fewer snapshots, Ops Manager does not delete existing snapshots to conform to the new schedule. To delete unneeded snapshots, see Delete Snapshots for Replica Sets and Sharded Clusters.

Excluded Namespaces

Excluded namespaces are databases or collections that Ops Manager will not back up. Exclude namespaces to prevent backing up collections that contain logging data, caches, or other ephemeral data. Excluding these kinds of databases and collections will allow you to reduce backup time and costs.

Storage Engine

When you enable backups for a cluster or replica set that runs on MongoDB 3.0 or higher, you can choose the storage engine for the backups. Your choices are the MMAPv1 engine or WiredTiger engine. If you do not specify a storage engine, Ops Manager uses MMAPv1 by default. For more information on storage engines, see Storage in the MongoDB manual.

You can choose a different storage engine for a backup than you do for the original data. There is no requirement that the storage engine for a backup match that of the data it replicates. If your original data uses MMAPv1, you can choose WiredTiger for backing up, and vice versa.

You can change the storage engine for a cluster or replica set’s backups at any time, but doing so requires an initial sync of the backup on the new engine.

If you choose the WiredTiger engine to back up a collection that already uses WiredTiger, the initial sync replicates all the collection’s WiredTiger options. For information on these options, see the storage.wiredTiger.collectionConfig section of the Configuration File Options page in the MongoDB manual.

For collections created after initial sync, the Backup Daemon uses its own defaults for storing data. The Daemon will not replicate any WiredTiger options for a collection created after iniitial sync.

Important

The storage engine chosen for a backup is independent from the storage engine used by the Backup Database. If the Backup Database uses the MMAPv1 storage engine, it can store backup snapshots for WiredTiger backup jobs in its blockstore.

Index collection options are never replicated.

Resyncing Production Deployments

For production deployments, it is recommended that as a best practice you periodically (annually) resync all backed-up replica sets. When you resync, data is read from a secondary in each replica set. During resync, no new snapshots are generated.

Checkpoints

For sharded clusters, checkpoints provide additional restore points between snapshots. With checkpoints enabled, Ops Manager Backup creates restoration points at configurable intervals of every 15, 30 or 60 minutes between snapshots.

To create a checkpoint, Ops Manager Backup stops the balancer and inserts a token into the oplog of each shard and config server in the cluster. These checkpoint tokens are lightweight and do not have a consequential impact on performance or disk use.

Backup does not require checkpoints, and they are disabled by default.

Restoring from a checkpoint requires Ops Manager Backup to apply the oplog of each shard and config server to the last snapshot captured before the checkpoint. Restoration from a checkpoint takes longer than restoration from a snapshot.

Snapshots when Agent Cannot Stop Balancer

For sharded clusters, Ops Manager disables the balancer before taking a cluster snapshot. In certain situations, such as a long migration or no running mongos, Ops Manager tries to disable the balancer but cannot. In such cases, Ops Manager will continue to take cluster snapshots but will flag the snapshots with a warning that data may be incomplete and/or inconsistent. Cluster snapshots taken during an active balancing operation run the risk of data loss or orphaned data.

Snapshots when Agent Cannot Contact a mongod

For sharded clusters, if the Backup Agent cannot reach a mongod instance, whether a shard or config server, then the agent cannot insert a synchronization oplog token. If this happens, Ops Manager will not create the snapshot and will display a warning message.