- 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¶
On this page
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 and Restore Sharded Clusters for more
information.
See MongoDB Backup Methods and Backup and Restore Sharded Clusters for complete information on backups in MongoDB and backups of sharded clusters in particular.
Prerequisites¶
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.
To backup all the databases in a cluster via mongodump
, you
should have the backup
role. The backup
role provides
all the needed privileges for backing up all database. The role confers no
additional access, in keeping with the policy of least privilege.
To backup a given database, you must have read
access on the database.
Several roles provide this access, including the backup
role.
To backup the system.profile
collection in a database, you must have
read
access on certain system collections in the database. Several roles
provide this access, including the clusterAdmin
and
dbAdmin
roles.
Changed in version 2.6.
To backup users and user-defined roles for a
given database, you must have access to the admin
database. MongoDB
stores the user data and role definitions for all databases in the
admin
database.
Specifically, to backup a given database’s users, you must have the
find
action on the admin
database’s admin.system.users
collection. The backup
and userAdminAnyDatabase
roles both provide this privilege.
To backup the user-defined roles on a database, you must have the
find
action on the admin
database’s
admin.system.roles
collection. Both the backup
and
userAdminAnyDatabase
roles provide this privilege.
Consideration¶
To create these backups of a sharded cluster, 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. 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.
Procedure¶
Disable the balancer process.¶
Disable the balancer process that equalizes the distribution of
data among the shards. To disable the balancer, use the
sh.stopBalancer()
method in the mongo
shell. For
example:
For more information, see the Disable the Balancer procedure.
Warning
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 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.
Backup one config server.¶
Run mongodump
against a config server mongod
instance to back up the cluster’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.
Backup replica set members.¶
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 mongodump
on the same system where the
mongod
ran. This operation will create a dump of all the
data managed by the mongod
instances that used the
dbPath
/data/db/
. mongodump
writes the output of this dump to the /data/backup/
directory.
Restart replica set members.¶
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 process.¶
Re-enable the balancer with the sh.setBalancerState()
method.
Use the following command sequence when connected to the
mongos
with the mongo
shell: