The restore procedure for a replica set documented here assumes that the backup being used does not include a local database.

In the case of a filesystem backup which contains a local database from an existing replica set member the steps are incorrect, i.e. there is no need to 'rs.initiate()' on the first node, nor 'rs.add()' on subsequent nodes. Indeed, the 'rs.initiate()' will fail in this case with an error:

replset:PRIMARY> rs.initiate()
{
	"info2" : "no configuration explicitly specified -- making one",
	"me" : "HAL.local:27017",
	"info" : "try querying local.system.replset to see current configuration",
	"ok" : 0,
	"errmsg" : "already initialized",
	"code" : 23
}

This is important in the case of WiredTiger in particular as there is no association between the files on disk and the databases they relate to. As such it is not possible to remove the 'local' database from the set of backup files being restored - the local database, if present, can only be removed if it is explicitly dropped from within the database (which requires following the maintenance procedure, see below).

This also applies to, for example, an MMAP node which is backed up with a filesystem snapshot and the complete snapshot is used to initialise the new node.

As an alternative the instructions can be updated to document how to remove the local database from the mongo shell (by starting the mongod process in maintenance mode, i.e., without the replSet parameter and on a different port, and then dropping the local database). After this the user can 'rs.initiate()' and use this host to seed the other members of the replica set. This process, however, assumes that you want to seed the full replica-set from just a single node and is not appropriate if you are want to restore all replica-set members from their own backup.