Navigation
This version will reach end of life on Feb 2018. To upgrade, go to the Learn more about upgrading your version of MongoDB.

Backup a Sharded Cluster with Filesystem Snapshots

Overview

Important

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 alternate procedure.

See MongoDB Backup Methods and Backup and Restore Sharded Clusters for 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.

Considerations

Storage Engine

The following procedure applies to the MMAPv1 storage engine only.

Balancing

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.

Precision

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.

Consistency

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 use db.fsyncLock() and db.fsyncUnLock() to capture a valid copy of your data.

Procedure

Important

The following procedure, which includes db.fsyncLock() and db.fsyncUnlock() operations, applies only to MongoDB instances using MMAPv1 storage engine.

1

Disable the balancer.

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.

Consider the following example:

use config
sh.stopBalancer()

For more information, see the Disable the Balancer procedure.

2

If necessary, lock one secondary member of each replica set in each shard.

If your mongod does not have journaling enabled or your journal and data files are on different volumes, you must lock your mongod before capturing a back up.

If your 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.

To lock a secondary, connect through the mongo shell to the secondary member’s mongod instance and issue the db.fsyncLock() method.

3

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.

Do this only if the config server has journaling enabled. Use the procedure in Backup and Restore with Filesystem Snapshots. Never use db.fsyncLock() on config databases.

Create a database dump to backup the config server.

Issue 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. For example:

mongodump --oplog
4

Back up the replica set members of the shards that you locked.

You may back up the shards in parallel. For each shard, create a snapshot. Use the procedure in Backup and Restore with Filesystem Snapshots.

5

Unlock locked replica set members.

If you locked any mongod instances to capture the backup, unlock them now.

Unlock all locked replica set members of each shard using the db.fsyncUnlock() method in the mongo shell.

6

Enable the balancer.

Re-enable the balancer with the sh.setBalancerState() method. Use the following command sequence when connected to the mongos with the mongo shell:

use config
sh.setBalancerState(true)

Additional Resources

See also MongoDB Cloud Manager for seamless automation, backup, and monitoring.