use config sh.setBalancerState( false ) 

For more information, see the Disable the Balancer (page 717) procedure. 

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

Step 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 (page 593) for more information. 

Step 3: Backup one config server. Run mongodump against a config server mongod instance to back up the clus- ter’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 (page 670). 

mongodump --oplog 

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

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

Step 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) 

## Schedule Backup Window for Sharded Clusters 

Overview In a sharded cluster , the balancer process is responsible for distributing sharded data around the cluster, so that each shard has roughly the same amount of data. 

However, when creating backups from a sharded cluster it is important that you disable the balancer while taking backups to ensure that no chunk migrations affect the content of the backup captured by the backup procedure. Using the procedure outlined in the section Disable the Balancer (page 717) you can manually stop the balancer process temporarily. As an alternative you can use this procedure to define a balancing window so that the balancer is always disabled during your automated backup operation. 

