DOCS-156 sharded clusters and replica sets

Author: Bob Grabar

source/administration/backups.txt

@@ -13,9 +13,11 @@ use with MongoDB. This document contains the following sections:
 - :ref:`block-level-backup` and :ref:`database-dumps` describe specific
   strategies.
 
-- :ref:`backups-with-sharding-and-replication` describes considerations
-  specific to :term:`replica sets <replica set>` and :term:`sharded
-  clusters <sharded cluster>`.
+- :ref:`sharded-cluster-backups` describes considerations specific to
+  :term:`sharded clusters <sharded cluster>`.
+
+- :ref:`replica-set-backups` describes considerations
+  specific to :term:`replica sets <replica set>`.
 
 .. _backup-overview:
 
@@ -63,7 +65,7 @@ practically, and not just theoretically, functional.
 .. _backup-considerations:
 
 Production Considerations for Backup Strategies
------------------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 When evaluating a backup strategy for your MongoDB deployment consider
 the following factors:
@@ -103,25 +105,14 @@ for your database. Remember that all backup plans must be:
 - Automated. Database backups need to run regularly and
   automatically. Also automate tests of backup restoration.
 
-.. _backups-with-sharding-and-replication:
-
-Sharded Cluster and Replica Set Backups
----------------------------------------
-
-The underlying architecture of :term:`sharded clusters <sharded
-cluster>` and :term:`replica sets <replica set>` presents several
-challenges for creating backups. This section describes how to make
-quality backups in environments with these configurations and how to
-perform restorations.
-
 .. _sharded-cluster-backups:
 
 Sharded Cluster Backup Considerations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 .. include:: /includes/note-shard-cluster-backup.rst
 
-Sharded clusters complicate backup operations, as distributed
+:term:`Sharded clusters <sharded cluster>` complicate backup operations, as distributed
 systems. True point-in-time backups are only possible when stopping all write
 activity from the application. To create a precise moment-in-time
 snapshot of a cluster, stop all application write activity to the
@@ -148,7 +139,7 @@ procedures:
 .. _replica-set-backups:
 
 Replica Set Backup Considerations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 In most cases, backing up data stored in a :term:`replica set` is
 similar to backing up data stored in a single instance. It's possible to
@@ -167,4 +158,4 @@ particularly advantageous in that the backup operation does not
 affect the performance of the primary or master. Replication
 itself provides some measure of redundancy. Nevertheless, keeping
 point-in time backups of your cluster to provide for disaster recovery
-and as an additional layer of protection is crucial.
+and as an additional layer of protection is crucial.

source/reference/command/fsync.txt

@@ -90,8 +90,7 @@ fsync
 
       :dbcommand:`fsync` lock is only possible on individual shards of
       a sharded cluster, not on the entire sharded cluster. To backup an
-      entire sharded cluster, please read :ref:`considerations for
-      backing up sharded clusters <backups-with-sharding-and-replication>`.
+      entire sharded cluster, please read :ref:`sharded-cluster-backups`.
 
       If your :program:`mongod` has :term:`journaling <journal>`
       enabled, consider using :ref:`another method