Mongodb – Mongo DB Backup & restore

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.

Original Answer (leaving for people that might hit this because of the simple explanation):

The clusterAdmin role only applies when you authenticate against the admin database, so unless you specify the --authenticationDatabase option to be admin when you are running mongodump/mongorestore I suspect you are getting a lesser privilege when authing against the DB you are dumping/restoring and hence seeing the errors.

Follow up:

This issue looks like a bug, but besides some tangential issues, I can't find an issue that corresponds to a fix here. As of writing this, there have been 2 major releases since 2.4.10 (released April 2014), and even 2.4 has several subsequent updates (2.4.15 was release April 2015). Normally I would recommend filing a bug but 2.4 has reached EOL, so unless you can reproduce this with 2.6 or 3.0 then it won't be actioned.

Additionally, the tools (dump, restore etc.) have since been completely refactored (even have their own repo and project) and are even written in a different language now.

I don't believe the errors are impacting your data dump, so it's up to you in terms of how much effort you want to expend on this, but at a minimum I would recommend upgrading to a non-EOL version of MongoDB and retrying your process.