- Administration >
- Administration Tutorials >
- Backup and Recovery >
- Backup and Restore Sharded Clusters >
- Backup a Sharded Cluster with Database Dumps
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 a Sharded Cluster with Filesystem Snapshots.
See MongoDB Backup Methods and Backup and Restore Sharded Clusters for a complete information on backups in MongoDB and backups of sharded clusters in particular.
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.
Procedure¶
In this procedure, you will stop the cluster balancer and take a backup
up of the config database, and then take backups of each
shard in the cluster using mongodump
to capture the backup
data. If you need an 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 of
time.
For approximate point-in-time snapshots, you can improve the quality of the backup while minimizing impact on the cluster by taking the backup from a secondary member of the replica set that provides each shard.
Disable the balancer process that equalizes the distribution of data among the shards. To disable the balancer, use the
sh.stopBalancer()
method in themongo
shell. For example:For more information, see the Disable the Balancer procedure.
Warning
It is essential that you stop the balancer before creating backups. If the balancer remains active, your resulting backups could have duplicate data or miss some data, as chunks migrate while recording backups.
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, you shut down one member of each replica set. 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.
Use
mongodump
with the--oplog
option to backup one of the config servers. This backs up the cluster’s metadata. You only need to back up one config server as they all hold the same data.Run
mongodump
against the config servermongod
instance; the config servermongod
instance must be version 2.4 or later and must run with the--configsvr
option.Back up the replica set members of the shards that shut down using
mongodump
and specifying the--dbpath
option. You may back up the shards in parallel. Consider the following invocation:You must run this command on the system where the
mongod
ran. This operation will use journaling and create a dump of the entiremongod
instance with data files stored in/data/db/
.mongodump
will write the output of this dump to the/data/backup/
directory.Restart all stopped replica set members of each shard as normal and allow them to catch up with the state of the primary.
Re-enable the balancer with the
sh.setBalancerState()
method.Use the following command sequence when connected to the
mongos
with themongo
shell: