(DOCSP-42952) Adds detail to note, fixes footnotes. (#519)

This PR: 
- Fixes the footnotes throughout [Backup
Preparations](https://www.mongodb.com/docs/ops-manager/v7.0/core/backup-preparations/#backup-preparations)
by converting the first two to asterisks and flattening an include.
- Copies a note to another appropriate section.
- The remaining ask in
[DOCSP-42952](https://jira.mongodb.org/browse/DOCSP-42952) is addressed
in another repo.

[DOCSP-42952](https://jira.mongodb.org/browse/DOCSP-42952)

[STAGING](https://deploy-preview-519--10gen-docs-ops-manager.netlify.app/core/backup-preparations/)

### Self-Review Checklist

- [ ]
[Define](https://wiki.corp.mongodb.com/display/DE/Taxonomy+tagging+instructions)
taxonomy
[values](https://wiki.corp.mongodb.com/display/DE/Docs+Taxonomy) at top
of page.
- [ ] Add genre facets (tutorial or reference), as in this [example
PR](10gen/cloud-docs#5042).
- [ ] Add programmingLanguage (if necessary).
- [ ] Add meta keywords (if necessary).
- [ ] Resolve any new warnings or errors in the build.
- [ ] Proofread for spelling and grammatical errors.
- [ ] Check staging for rendering issues.
- [ ] Confirm links are working.

Author: erabil-mdb

source/core/backup-preparations.txt

@@ -84,8 +84,8 @@ Backup Method Features
      - MongoDB Blockstore
 
    * - Snapshot Types
-     - Complete [1]_
-     - Complete [1]_
+     - Complete ***** 
+     - Complete ***** 
      - Many partial
      - Many partial
      - Many partial
@@ -132,20 +132,19 @@ Backup Method Features
      - Lower
      - Medium
 
-.. [1]
-       To perform an incremental backup to a
-       :term:`File System Store`, the {+mdbagent+}
-       slices each :manual:`storage engine </core/storage-engines/>`
-       file in the path specified for backup into block(s) of
-       data and transfers only changed block(s) to |onprem|.
-       |onprem| creates a new :manual:`snapshot </reference/glossary/#std-term-snapshot>` from received
-       block(s) and copies the remaining unchanged block(s)
-       from the previous full backup snapshot. Each incremental
-       backup snapshot stored to a file system saves
-       network I/O. Each such backup snapshot contains a full
-       copy of all required files from a backed up MongoDB
-       deployment and does not :term:`de-duplicate <deduplication>`
-       records.
+***** To perform an incremental backup to a
+:term:`File System Store`, the {+mdbagent+}
+slices each :manual:`storage engine </core/storage-engines/>`
+file in the path specified for backup into block(s) of
+data and transfers only changed block(s) to |onprem|.
+|onprem| creates a new :manual:`snapshot </reference/glossary/#std-term-snapshot>` from received
+block(s) and copies the remaining unchanged block(s)
+from the previous full backup snapshot. Each incremental
+backup snapshot stored to a file system saves
+network I/O. Each such backup snapshot contains a full
+copy of all required files from a backed up MongoDB
+deployment and does not :term:`de-duplicate <deduplication>`
+records.
 
 .. note:: **When Do You Use a Particular Backup Method?**
 
@@ -186,7 +185,45 @@ your database increases beyond 2 TB of uncompressed data:
 
    .. include:: /includes/backup/fact-backup-with-blockstores.rst
 
-.. include:: /includes/fact-backup-sizing-recommendation.rst
+These size recommendations are a best practice. They are not a
+limitation of the MongoDB database or |mms|.
+
+Backup and restore can use large amounts of CPU, memory, storage, 
+and network bandwidth.
+
+.. example::
+
+   Your stated network throughput, such as 10 Gbps or 100 Gbps, is 
+   a *theoretical* maximum. That value doesn't account for sharing 
+   or throttling of network traffic.
+
+   Consider the following scenario:
+
+   - You want to back up a 2 TB database.
+   - Your hosts support a 10 Gbps TCP connection from |mms| to its
+     backup storage.
+   - The network connection has very low packet loss and a low round
+     trip delay time.
+
+   A *full* backup of your data would take *more than 30 hours to
+   complete*. [#]_
+
+   This doesn't account for disk read and write speeds, which can be,
+   at most, 3 Gbps reads and 1 Gbps writes for a single or mirrored
+   NVMe storage device.
+
+   The time required to complete each successive incremental backup
+   depends on write load.
+
+   If you :doc:`shard this database 
+   </tutorial/convert-replica-set-to-sharded-cluster>`
+   into 4 shards, each shard runs its backup separately. This results
+   in a backup that takes less than 8 hours to complete.
+
+   .. [#]
+      These throughput figures were calculated using the `Network
+      Throughput Calculator <https://wintelguy.com/wanperf.pl>`__ and
+      assume no additional network compression.
 
 .. _snapshot-frequency-and-retention:
 
@@ -380,6 +417,10 @@ For clusters running MongoDB version 4.0 and earlier:
 Databases Running FCV 4.2 and Later
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
+.. important::
+
+   .. include:: /includes/fact-backup-standalone-restriction.rst
+
 .. include:: /release-notes/release-advisories/advisories-v4.2-backup.rst
 
 .. cond:: onprem

source/includes/fact-backup-sizing-recommendation.rst

@@ -19,7 +19,7 @@ and network bandwidth.
      trip delay time.
 
    A *full* backup of your data would take *more than 30 hours to
-   complete*. [*]_
+   complete*. [#]_
 
    This doesn't account for disk read and write speeds, which can be,
    at most, 3 Gbps reads and 1 Gbps writes for a single or mirrored
@@ -33,7 +33,7 @@ and network bandwidth.
    into 4 shards, each shard runs its backup separately. This results
    in a backup that takes less than 8 hours to complete.
 
-   .. [*]
+   .. [#]
       These throughput figures were calculated using the `Network
       Throughput Calculator <https://wintelguy.com/wanperf.pl>`__ and
       assume no additional network compression.

source/includes/fact-backup-standalone-restriction.rst

@@ -1,3 +1,5 @@
-Only sharded clusters or replica sets can be backed up. To back up a
-standalone :manual:`mongod </reference/program/mongod/#mongodb-binary-bin.mongod>` process, you must
+Sharded clusters and replica sets are the only deployment types you can back up if
+your databases run MongoDB FCV 4.2 and earlier. To back up a
+standalone :manual:`mongod </reference/program/mongod/#mongodb-binary-bin.mongod>` process
+running MongoDB FCV 4.2 or earlier, you must
 :doc:`convert it to a single-member replica set </tutorial/convert-standalone-to-replica-set>`.