(DOCSP-45891) Revises per explicit edits from v1 review. (#51)

* (DOCSP-45891) Revises per explicit edits from v1 review.

* Revises per copy review.

Author: erabil-mdb

source/backups.txt

@@ -97,7 +97,9 @@ provider.
        specified by you, guaranteeing that your backups are fully WORM
        (Write Once Read Many) compliant. Only a designated, authorized
        user can turn off this protection after completing a verification
-       process with MongoDB support.  
+       process with MongoDB support and legal. This adds a mandatory manual 
+       delay and cooldown period so that an attacker cannot change the backup 
+       policy and export the data. To learn more, see `Configure a Backup Compliance Policy <https://www.mongodb.com/docs/atlas/backup/cloud-backup/backup-compliance-policy/>`__.
 
 Recommendations for Backup Strategy
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -115,17 +117,19 @@ for RTO, RPO, and the backup retention period will influence the cost
 and performance considerations of maintaining backups. In development
 and test environments, we recommend that you disable backup to save
 costs. In staging and production environments, ensure that backup is
-enabled in your deployment template.
+enabled in your deployment template and that you have successfully tested 
+your backup and restore procedure and process.
 
 Large replica sets (and shards) take longer to restore from backup. 
 In staging and production environments, through testing techniques, we
 recommend that you identify replica set size or shard size limits to
 ensure that your size is compatible with RTO requirements. Ensure that 
 snapshot schedule and retention policies meet any RPO requirements. 
 
-In addition to |service| cloud backups, we recommend that you enable
-continuous cloud backups with a restore window of seven days. This will
-allow you to replay the Oplog to restore a {+cluster+} from a particular
+In production and in addition to |service| cloud backups, we recommend that you start
+with a default of continuous cloud backups with a restore window of seven days. 
+Adjust this time range with a longer setting based on the criticality of the workload.
+This allows you to replay the oplog to restore a {+cluster+} from a particular
 point in time. 
 
 Recommendations for Backup Snapshots 
@@ -195,7 +199,7 @@ Distribution copies backups to two secondary regions, enabling restores
 in 15 minutes or less by using backup copies. By selecting only 
 hourly and daily snapshots along with the oplog for regional copies, you
 can optimize costs while ensuring rapid recovery during regional
-outages. Once restored, you can simply point your application to the new 
+outages. Once restored, you can point your application to the new 
 {+cluster+} to regain full functionality with complete read and write
 capabilities. We recommend developing automated deployment templates
 that strike a balance between availability and cost. However, your
@@ -205,7 +209,7 @@ locations.
 Recommendations for Backup Compliance Policy 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-We recommend enforcing |service|'s Backup Compliance Policy to prevent
+We recommend enforcing |service|'s `Backup Compliance Policy <https://www.mongodb.com/docs/atlas/backup/cloud-backup/backup-compliance-policy/>`__ to prevent
 unauthorized modifications or deletions of backups, thereby maintaining
 data integrity and supporting robust disaster recovery.  
 
@@ -229,7 +233,10 @@ Recommendations for Backup Costs
 
 To optimize |service| backup costs, you must adjust the backup frequency
 and retention policies to align with data criticality, reducing
-unnecessary storage expenses. You can also use incremental backups and
+unnecessary storage expenses. For example, you should disable backups in lower 
+environments, and ensure that in upper environments with high availability requirements 
+you are distributing backups to each region where you are deployed.
+You can also use incremental backups and
 built-in compression to minimize the amount of stored data. By selecting
 regions strategically for backup, you can avoid cross-region data
 transfer fees and choose the right cluster size based on workload to
@@ -256,7 +263,7 @@ backup is enabled for the {+cluster+}.
       .. include:: /includes/examples/cli-example-backup-take-snapshot.rst
 
       Enable backup compliance policy for your project with a
-      designated, authorized user named ``john doe`` who alone can turn
+      designated, authorized user (``[email protected]``) who alone can turn
       off this protection after completing a verification process with
       MongoDB support. 
 

source/includes/examples/cli-example-backup-compliance-policy-enable.rst

@@ -3,6 +3,6 @@
 
    atlas backups compliancePolicy enable \ 
      --projectId 67212db237c5766221eb6ad9 \
-     --authorizedEmail myemail@example.com \
+     --authorizedEmail governance@example.org \
      --authorizedUserFirstName john \
      --authorizedUserLastName doe