Moving MongoDB shards from one server to another
You are not copying the contents of the config servers and effectively creating a new sharded deployment rather than restoring a backup of an existing one. Config servers include essential information about where data lives in a sharded deployment, so you must backup &amp; restore the config server data along with the shards.

Note: there have been changes to sharded cluster configuration in successive releases, so make sure you are using documentation for the correct MongoDB release series. The links below are specific to MongoDB 3.0.

For supported backup approaches see the MongoDB 3.0 Backup &amp; Restore a Sharded Cluster tutorials.


  sh.addShard("localhost:27010") 
  
  sh.addShard("localhost:27011")


If you've restored a sharded cluster from a backup, the shards will already be configured. If host names have changed from the original deployment, you will need to update the config.shards information  via a mongos rather than adding new shards (and then restart the mongod instances in your sharded cluster to ensure the new names are used). See the MongoDB 3.0 Restore a Sharded Cluster tutorial for more specific details.


  sh.shardCollection("log", {"id" : 1, "eventId": 1})


If a sharded cluster is already configured,  sharding an existing sharded collection will return an error. Since you ran this command starting from fresh config server data, the sh.shardCollection() command will be unaware of how existing data is distributed on the shards and assume that the primary shard for a database with an unsharded collection has the full range of data.