Activate Backup for a Sharded Cluster¶

On this page

Overview
Considerations
Prerequisites
Procedure

Overview¶

You can start, restart, stop, and terminate backups for a sharded cluster. As appropriate, you also can specify which instance to use for the initial sync, exclude namespaces, authenticate, and change the snapshot schedule and retention.

Note

The sharded cluster must be MongoDB version 2.4.3+ or 2.6. MMS 1.5 does not support MongoDB 3.0.

Considerations¶

Excluded Namespaces¶

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

Snapshot Frequency and Retention Policy¶

You can take snapshots every 6, 8, 12, or 24 hours and save them for 2-5 days. MMS can retain daily snapshots for up to 365 days, weekly snapshots for up to 52 weeks, and monthly snapshots for up to 36 months.

By default, MMS takes snapshots every 6 hours and stores these for 2 days, for use in point-in-time restores. Also by default, MMS retains daily snapshots for a week, weekly snapshots for a month, and monthly snapshots for a year.

You can set point-in-time restores going back 1, 2, 3, or 4 days.

Changes to the snapshot schedule will affect your snapshot storage costs. The longer your snapshot window, the longer it will take to build a point in time restore.

Checkpoints¶

Checkpoints provide additional restore points between snapshots. With checkpoints enabled, MMS Backup creates restoration points at configurable intervals of every 15, 30 or 60 minutes between snapshots.

To create a checkpoint, MMS 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.

MMS backup does not require checkpoints: by default, MMS does not enable checkpoints.

Restoring from a checkpoint requires MMS 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¶

Changed in version 2.4: (Backup Agent)

In normal operation, MMS disables the balancer before taking a cluster snapshot. In certain situations, such as a long migration or no running mongos, MMS tries to disable the balancer but cannot. In such cases, MMS 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 the risk of containing data loss or orphaned data.

Snapshots when Agent Cannot Contact a `mongod`¶

Changed in version 2.4: (Backup Agent)

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, MMS will not create the snapshot and will display a warning message.

Prerequisites¶

Before enabling backup, ensure that the following is true for all replica sets that you back up:

MMS Monitoring is actively collecting data from your cluster, including from at least one mongos.
All the cluster’s config servers are running, and the balancing round has completed within the last hour.
There is an active primary.
If you explicitly select a sync target, ensure that the sync target is accessible on the network and keeping up with replication.

Procedure¶

1

Select the Backup tab and then select Sharded Cluster Status.¶

2

Click the Start button for the sharded cluster.¶

The Start Backups for Sharded Clusters interface will appear with options to select the mongod to use as sync source, configure authentication, and manage any excluded namespaces.

3

Select which instances to use for the initial sync source.¶

To minimize the impact on the primaries, sync off of the secondaries.

4

If using access control, specify mechanism and credentials, as needed.¶

Auth Mechanism	The authentication mechanism used by the host. Can specify MONGODB-CR, LDAP (PLAIN), or Kerberos(GSSAPI).
Current DB Username	If the authentication mechanism is MONGODB-CR or LDAP, the username used to authenticate the Monitoring Agent to the MongoDB deployment. See Configure Backup Agent for MONGODB-CR, Configure Backup Agent for LDAP Authentication, or Configure the Backup Agent for Kerberos for setting up user credentials.
Current DB Password	If the authentication mechanism is MONGODB-CR or LDAP, the password used to authenticate the Monitoring Agent to the MongoDB deployment. See Configure Backup Agent for MONGODB-CR, Configure Backup Agent for LDAP Authentication, or Configure the Backup Agent for Kerberos for setting up user credentials.
My deployment supports SSL for MongoDB connections	If checked, the Monitoring Agent must have a trusted CA certificate in order to connect to the MongoDB instances. See Configure Monitoring Agent for SSL.

You can optionally configure authentication credentials later through the deployment’s gear icon.

5

To exclude namespaces from the backup, click the Manage excluded namespaces button.¶

Enter the namespaces to exclude and click Save.

You can optionally add or remove exclude namespaces later through the deployment’s gear icon.

6

Click Start.¶

Your Backup Agent will start polling the specified instance for this sharded cluster.

← Activate Backup for a Replica Set Restore MongoDB Instances with MMS Backup →