MongoDB – Difference Between mongodump and mongoexport

A mongodump and mongorestore (or a similar script to accomplish the same thing) to backup and re-import the data is the most straight forward way of doing this at the moment until SERVER-6063 is implemented.

The only other option I can think of would be to move all chunks to a single shard, wipe out the sharding config for the collection (effectively unsharding it) and then do the rename on that shard. Once that was complete, you could re-shard the collection.

This would be:

1. Dangerous (messing with the config meta data is always a bad idea)
2. Unsupported (if you get into trouble, it's probably up to you to fix it)
3. More complicated (since the first recommended thing to do would be to backup your data via mongodump)

As one other alternative - can you move everything else (perhaps unsharded) out of this database? Obviously this would not be helpful if you have other large sharded collections in this DB, but just wanted to make sure it was considered.

I found a an old doc (v3.0) Backup a Small Sharded Cluster with mongodump. This documentation doesn't exists anymore in new MongoDB versions.

This procedure is only for backing up the data from a small sharded cluster and does not cover recreating the sharded environment or capturing a point-in-time backup. As you've noticed, there is no mention of backing up the config server data or other essential steps that would be required for a sharded environment (for example, stopping the balancer). This procedure would perhaps be suitable for backing up data from a development or staging environment, but is not recommendable for a typical production environment.

For a more complete sharded backup procedure using mongodump, see: Back Up a Sharded Cluster with Database Dumps. Please ensure the version of the documentation you are referencing matches your MongoDB release series as there may be notable differences.

However, you mentioned using MongoDB Ops Manager which includes a specific feature for backing up sharded clusters. If you choose the option for a manual restore, Ops Manager will provide archive files to restore the config servers and shards. Since Ops Manager licensing is part of a MongoDB Enterprise subscription, I would recommend raising a commercial support case with MongoDB if you need recommendations or clarification on any of the procedures or your requirements.

what is a small data set in GB?

There isn't an absolute number. General factors include resource challenges such as the size of your data relative to RAM, available network bandwidth, and how quickly your data changes. Typically if you have sufficient data or workload to warrant sharding, you've also outgrown mongodump as a backup approach.

mongodump is going to read all data into memory which will have significant impact on working sets for shards if your data is much larger than available RAM. You also need to have enough disk space to save a complete backup (or compressed backup for MongoDB 3.2+) of the data dumped via a single mongos, enough network bandwidth to cope with the increased traffic, etc.

For your specific use case mongodump definitely isn't a recommendable strategy for several strong reasons:

• this is a production environment
• you want to clone/recreate the sharded cluster in another environment
• you have access to MongoDB Ops Manager for backup