Backing-up the MongoDB’s sharded cluster

Considerations :
1) Stop the balancer before capturing a backup.
If the balancer is active while you capture backups, the backup artifacts may be incomplete and/or have duplicate data, as chunks may migrate while recording backups.

2) Take a backup up of the config database, and then take backups of each shard in the cluster using a file-system snapshot tool.
You need to stop all application writes for an exact moment-in-time snapshot.
For approximate point-in-time snapshots, you can minimize the impact on the cluster by taking the backup from a secondary member of each replica set shard.

3) If the journal and data files are on the same logical volume, you can use a single point-in-time snapshot to capture a consistent copy of the data files.
If the journal and data files are on different file systems, you must use db.fsyncLock() and db.fsyncUnlock() to ensure that the data files do not change, providing consistency for the purposes of creating backups.

Process :

1) Stop the balancer

mongos> use config
mongos> sh.stopBalancer()

2) Lock one secondary member of each replica set in each shard

E.g.,

rs1:SECONDARY> db.fsyncLock()
rs2:SECONDARY> db.fsyncLock()
rs3:SECONDARY> db.fsyncLock()

If your secondary has journaling enabled and its journal and data files are on the same volume, you may skip this step.
3) Back up one of the config servers.

You need back up only one config server, as they all hold the same data.

]$ mongodump –oplog
4) Back up the replica set members of the shards that you locked.

You may back up the shards in parallel. For each shard, create a snapshot.
5) Unlock locked replica set members.
db.fsyncUnlock()

6) Enable the balancer

mongos> use config
mongos> sh.setBalancerState(true)