Backup a Sharded Cluster with Filesystem Snapshots¶
The following procedure applies to the MMAPv1 storage engine only.
This document describes a procedure for taking a backup of all
components of a sharded cluster. This procedure uses file system
snapshots to capture a copy of the
mongod instance. An
alternate procedure uses
mongodump to create binary
database dumps when file-system snapshots are not available. See
Backup a Sharded Cluster with Database Dumps for the
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.
It is essential that you 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.
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 a file-system snapshot tool. 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 in 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.
If the journal and data files are on the same logical volume, you can use a single point-in-time snapshot to capture a valid copy of the data.
If the journal and data files are on different file systems, you must
db.fsyncUnLock() to capture
a valid copy of your data.
Disable the balancer.¶
Consider the following example:
use config sh.stopBalancer()
For more information, see the Disable the Balancer procedure.
If necessary, lock one secondary member of each replica set in each shard.¶
mongod has journaling enabled and your journal
and data files are on the same volume, you may skip this step.
If you need to lock the
mongod, attempt to lock one
secondary 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.
Back up one of the config servers.¶
Backing up a config server backs up the sharded cluster’s metadata. You need back up only one config server, as they all hold the same data. Do one of the following to back up one of the config servers:
Create a file-system snapshot of the config server.¶
Create a database dump to backup the config server.¶
mongodump against one of the config
mongod instances. If you are
running MongoDB 2.4 or later with the
--configsvr option, then include the
--oplog option to ensure that the dump
includes a partial oplog
containing operations from the duration of the mongodump operation.