DOCS-385 change to clarifiy recovery on replica sets

Author: Sam Kleinman

source/tutorial/recover-data-following-unexpected-shutdown.txt

@@ -15,8 +15,12 @@ milliseconds by default, and ensures that MongoDB will be able to
 recover a constant state even in the case of an unclean shutdown due to
 power loss or other system failure.
 
-If you do not have journaling enabled, use the following procedure to
-recover data that may be in an inconsistent state.
+If you are *not* running as part of a :term:`replica set` **and** do
+*not* have journaling enabled use the following procedure to recover
+data that may be in an inconsistent state. If you are running as part
+of a replica set, you should *always* restore from a backup or restart
+the :program:`mongod` instance with an empty :setting:`dbpath` and
+allow MongoDB to resync the data.
 
 .. seealso:: The ":doc:`/administration`" documents and the
    documentation of the :setting:`repair`, :setting:`repairpath`, and
@@ -34,8 +38,10 @@ Indications
 ~~~~~~~~~~~
 
 When you are aware of a :program:`mongod` instance running without
-journaling that stops unexpectedly, you should always run the repair
-operation before starting MongoDB again.
+journaling that stops unexpectedly **and** you're not running with
+replication, you should always run the repair operation before
+starting MongoDB again. If you're using replication, then restore from
+a backup and allow replication to synchronize your data.
 
 If the ``mongod.lock`` file in the data directory specified by
 :setting:`dbpath`, ``/data/db`` by default, is *not* a zero-byte file,