Backup a Sharded Cluster with Database Dumps¶

Overview¶

This document describes a procedure for taking a backup of all components of a sharded cluster. This procedure uses mongodump to create dumps of the mongod instance. An alternate procedure uses file system snapshots to capture the backup data, and may be more efficient in some situations if your system configuration allows file system backups. See Backup and Restore Sharded Clusters for more information.

See MongoDB Backup Methods and Backup and Restore Sharded Clusters for complete information on backups in MongoDB and backups of sharded clusters in particular.

Prerequisites¶

Important

To capture a point-in-time backup from a sharded cluster you must stop all writes to the cluster. On a running production system, you can only capture an approximation of point-in-time snapshot.

To back up all the databases in a cluster via mongodump, you should have the backup role. The backup role provides the required privileges for backing up all databases. The role confers no additional access, in keeping with the policy of least privilege.

To back up a given database, you must have read access on the database. Several roles provide this access, including the backup role.

To back up the system.profile collection, which is created when you activate database profiling, you must have additional read access on this collection. Several roles provide this access, including the clusterAdmin and dbAdmin roles.

Changed in version 2.6.

To back up users and user-defined roles for a given database, you must have access to the admin database. MongoDB stores the user data and role definitions for all databases in the admin database.

Specifically, to back up a given database’s users, you must have the find action on the admin database’s admin.system.users collection. The backup and userAdminAnyDatabase roles both provide this privilege.

To back up the user-defined roles on a database, you must have the find action on the admin database’s admin.system.roles collection. Both the backup and userAdminAnyDatabase roles provide this privilege.

Consideration¶

To create these backups of a sharded cluster, you will stop the cluster balancer and take a backup of the config database, and then take backups of each shard in the cluster using mongodump to capture the backup data. To capture a more exact moment-in-time snapshot of the system, you will need to stop all application writes before taking the filesystem snapshots; otherwise the snapshot will only approximate a moment in time.

For approximate point-in-time snapshots, taking the backup from a single offline secondary member of the replica set that provides each shard can improve the quality of the backup while minimizing impact on the cluster.

Procedure¶

1

Disable the balancer process.¶

Disable the balancer process that equalizes the distribution of data among the shards. To disable the balancer, use the sh.stopBalancer() method in the mongo shell. For example:

use config
sh.setBalancerState(false)

For more information, see the Disable the Balancer procedure.

Warning

If you do not stop the balancer, the backup could have duplicate data or omit data as chunks migrate while recording backups.

2

Lock replica set members.¶

Lock one member of each replica set in each shard so that your backups reflect the state of your database at the nearest possible approximation of a single moment in time. Lock these mongod instances in as short of an interval as possible.

To lock or freeze a sharded cluster, issue db.fsyncLock() on a member of each replica set in the cluster. Ensure that the oplog has sufficient capacity to allow these secondaries to catch up to the state of the primaries after finishing the backup procedure. See Oplog Size for more information.

3

Backup one config server.¶

Run mongodump against a config server mongod instance to back up the cluster’s metadata. The config server mongod instance must be version 2.4 or later and must run with the --configsvr option. You only need to back up one config server.

Use mongodump with the --oplog option to backup one of the config servers.

mongodump --oplog

4

Backup replica set members.¶

Back up the “frozen” replica set members of the shards using mongodump and specifying the --oplog option. You may back up the shards in parallel. Consider the following invocation:

mongodump --oplog --out /data/backup/

You must run mongodump on the same system where the mongod ran. mongodump writes the output of this dump as well as the oplog.bson file to the /data/backup/ directory.

5

Unlock replica set members.¶

Use db.fsyncUnlock() to unlock the locked replica set members of each shard. Allow these members to catch up with the state of the primary.

6

Re-enable the balancer process.¶

Re-enable the balancer with the sh.setBalancerState() method.

Use the following command sequence when connected to the mongos with the mongo shell:

use config
sh.setBalancerState(true)

← Backup a Sharded Cluster with Filesystem Snapshots Schedule Backup Window for Sharded Clusters →

Was this page helpful?

Yes No

Thank you for your feedback!

We're sorry! You can Report a Problem to help us improve this page.