Mongodb – How to update collections and restore while doing mongorestore

With a single node i don't think you have other option than mongodump and LVM snapshot. In the case you run on a replica set which is recommended for production you can just stop one secondary and copy the data directory.

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