Changed in version 3.2: Starting in MongoDB 3.2, the following procedure can be used with the
MMAPv1 and the WiredTiger storage engines. With previous versions of
MongoDB, the procedure applied to MMAPv1 only.

The backup role provides the required privileges to perform
backup on a sharded cluster that has access control enabled.

Changed in version 3.2.1: The backup role provides additional privileges to back
up the system.profile
collections that exist when running with database profiling. Previously, users required an additional
read access on this collection.

To create backups of a sharded cluster, you will stop the
cluster balancer, 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, you can minimize the impact on
the cluster by taking the backup from a secondary member of each
replica set shard.

If locking a secondary of the CSRS, confirm that the member has
replicated data up to some control point. To verify, first connect a
mongo shell to the CSRS primary and perform a write
operation with "majority" write concern on a
control collection:

If the secondary member contains the latest control document, it
is safe to lock the member. Otherwise, wait until the member
contains the document or select a different secondary member
that contains the latest control document.

Run mongodump against a config server mongod
instance to back up the cluster’s metadata. You only need to back up
one config server. If you are using CSRS config servers and locked a
config server secondary in the previous step, perform this step
against the locked config server.

If your deployment uses CSRS config servers, unlock the config server
node before proceeding to the next step.
To unlock the CSRS member, use db.fsyncUnlock() method in
the mongo shell used to lock the instance.