diff --git a/source/administration/backups.txt b/source/administration/backups.txt
index 4c6c67c2e4c..cd1f5ddb655 100644
--- a/source/administration/backups.txt
+++ b/source/administration/backups.txt
@@ -60,36 +60,44 @@ Approaches to Backing Up MongoDB Systems
 ----------------------------------------
 
 There are two main methodologies for backing up MongoDB
-instances. Creating binary "dumps" of the database using
-:program:`mongodump` or creating filesystem level snapshots. Both
-methodologies have advantages and disadvantages:
+instances; creating binary "dumps" of the database using
+:program:`mongodump` or creating filesystem level snapshots.
 
 - binary database dumps are comparatively small, because they don't
-  include index content or pre-allocated free space, and :ref:`record
-  padding <write-operations-padding-factor>`. However, it's impossible to
-  capture a copy of a running system that reflects a single moment in
-  time using a binary dump.
+  include index content, pre-allocated free space, or :ref:`record
+  padding <write-operations-padding-factor>`, but can take significant
+  time to complete.
 
-- filesystem snapshots, sometimes called block level backups, produce
-  larger backup sizes, but complete quickly and can reflect a single
-  moment in time on a running system. However, snapshot systems
-  require filesystem and operating system support and tools.
+- filesystem snapshots, sometimes called block-level backups, complete
+  quickly, but produce larger backup sizes and require filesystem and
+  operating system support and tools.
 
 The best option depends on the requirements of your deployment and
-disaster recovery needs. Typically, filesystem snapshots are because
-of their accuracy and simplicity; however, :program:`mongodump` is a
-viable option used often to generate backups of MongoDB systems.
+disaster recovery needs. The following topics provide details and
+procedures on the two approaches:
 
-The following topics provide details and procedures on the two approaches:
-
-- :doc:`/tutorial/backup-databases-with-filesystem-snapshots`.
 - :doc:`/tutorial/backup-databases-with-binary-database-dumps`.
+- :doc:`/tutorial/backup-databases-with-filesystem-snapshots`.
 
 In some cases, taking backups is difficult or impossible because of
 large data volumes, distributed architectures, and data transmission
 speeds. In these situations, increase the number of members in your
 replica set or sets.
 
+Another issue to be considered is how closely a backup can represent a
+single moment in time. This is possible with both binary dumps
+[#oplog]_ and filesystem snapshots if a single node contains the
+complete data set. However, the situation becomes more complex when a
+single node does not contain the complete data set, as with
+:term:`sharded clusters <sharded cluster>` 
+
+.. [#oplog] By default, the :program:`mongodump` command does not
+   include operations after execution has started. However, the
+   :option:`--oplog <mongodump --oplog>` option causes the :term:`oplog`
+   to be included in the dump, which can then be restored using the
+   :program:`mongorestore` :option:`--oplogReplay <mongorestore
+   --oplogReplay>` option.
+
 Backup Strategies for MongoDB Deployments
 -----------------------------------------