MongoDB Documentation, Release 3.0.4 Procedure Backup a Sharded Cluster with Filesystem Snapshots Considerations 256 Chapter 5. Administration Capture Data You can perform a backup of a sharded cluster by connecting mongodump to a mongos . Use the following operation at your system’s prompt: mongodump --host mongos3.example.net --port 27017 mongodump will write BSON files that hold a copy of data stored in the sharded cluster accessible via the mongos listening on port 27017 of the mongos3.example.net host. Restore Data Backups created with mongodump do not reflect the chunks or the distribution of data in the sharded collection or collections. Like all mongodump output, these backups contain separate directories for each database and BSON files for each collection in that database. You can restore mongodump output to any MongoDB instance, including a standalone, a replica set , or a new sharded cluster . When restoring data to sharded cluster, you must deploy and configure sharding before restoring data from the backup. See Deploy a Sharded Cluster (page 691) for more information. Overview This document describes a procedure for taking a backup of all components of a sharded cluster. This pro- cedure 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 (page 258) for the alternate procedure. See MongoDB Backup Methods (page 184) and Backup and Restore Sharded Clusters (page 254) for complete infor- mation 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. 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.