Backup a Sharded Cluster with Database Dumps¶
The following procedure applies to MongoDB instances using the MMAPv1 storage engine.
This document describes a procedure for taking a backup of all
components of a sharded cluster. This procedure
mongodump to create dumps of the
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
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.
backup role provides the required privileges to perform
backup on a sharded cluster that has access control enabled.
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.
Disable the balancer process.¶
use config sh.setBalancerState(false)
For more information, see the Disable the Balancer procedure.
If you do not stop the balancer, the backup could have duplicate data or omit data as chunks migrate while recording backups.
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
instances in as short of an interval as possible.
To lock or freeze a sharded cluster, issue
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.
Backup one config server.¶
mongodump against a config server
instance to back up the cluster’s metadata. The config server
mongod instance must be version 2.4 or later and must run
--configsvr option. You only need to back up one
Backup replica set members.¶
mongodump --oplog --out /data/backup/