edits to recovery document

Author: barriesegal

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

@@ -6,13 +6,13 @@ Recover MongoDB Data following Unexpected Shutdown
 
 If MongoDB does not shutdown cleanly [#clean-shutdown]_ the on-disk
 representation of the data files will likely reflect an inconsistent
-state which leads to data corruption.
+state which could lead to data corruption.
 
 To prevent data inconsistency and corruption, always shut down the
 database cleanly, and use the :ref:`durability journaling
 <setting-journal>`. The journal writes data to disk every 100
-milliseconds by default, and ensurers that MongoDB will be able to
-recover a constant state even in the case of a unclean shutdown due to
+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
@@ -34,7 +34,7 @@ Indications
 ~~~~~~~~~~~
 
 When you are aware of a :program:`mongod` instance running without
-journaling that stops unexpectedly you should always run the repair
+journaling that stops unexpectedly, you should always run the repair
 operation before starting MongoDB again.
 
 If the ``mongod.lock`` file in the data directory specified by
@@ -57,7 +57,7 @@ contains the following line:
    old lock file: /data/db/mongod.lock. probably means unclean shutdown
 
 You must remove the lockfile **and** run the repair operation before
-starting the database normally using the following procedure.
+starting the database normally using the following procedure:
 
 Overview
 ~~~~~~~~
@@ -149,12 +149,14 @@ the following procedure:
 
 In normal operation, you should **never** remove the ``mongod.lock``
 file and start :program:`mongod`. Instead use one of the above methods
-to recover the database and remove the lock files. In dire you
-situations can remove the lockfile, and start the database using the
+to recover the database and remove the lock files. In dire 
+situations you can remove the lockfile, and start the database using the
 possibly corrupt files, and attempt to recover data from the database;
 however, it's impossible to predict the state of the database in these
 situations.
 
 If you are not running with journaling, and your database shuts down
-unexpectedly for *any* reason, you should always assume that your
-database is in an inconsistent and likely corrupt state.
+unexpectedly for *any* reason, you should always proceed *as if* your database
+is in an inconsistent and likely corrupt state. If at all possible restore
+from :doc:`backup </administration/backup>` or if running as a :term:`replica
+set` re-sync from an intact member of the set.