DOCSP-43349 Backups doc (#25)

* DOCSP-43349 Backups doc

* Apply suggestions from code review

Co-authored-by: Sarah Simpers <[email protected]>

* DOCSP-43349 updates for SS feedback

* DOCSP-43349 updates for LA's feedback

---------

Co-authored-by: Sarah Simpers <[email protected]>

Author: kanchana-mongodb

source/backups.txt

@@ -6,48 +6,320 @@ Backups
 
 .. default-domain:: mongodb
 
+.. facet::
+   :name: genre
+   :values: reference
+
+.. meta::
+   :keywords: atlas architecture center
+   :description: Learn the best practices for configuring backups for you Atlas cluster.
+
 .. contents:: On this page
    :local:
    :backlinks: none
-   :depth: 1
+   :depth: 2
    :class: onecol
 
-Intro statement
+|service-fullname| provides fully managed and customizable backups to
+ensure data retention and recovery: 
+
+- Cloud Backups: Taken using the native snapshot capabilities of your
+  cloud provider, to support full-copy snapshots and localized snapshot
+  storage. These snapshots are always incremental in nature and leverage
+  the cloud provider's underlying backup snapshot mechanism for low cost
+  and fast restores. You choose a backup policy that specifies a certain
+  number of daily, weekly, and monthly snapshots.
+- Continuous Cloud Backups: This is an additive feature to the cloud
+  backups. It captures the full oplog for a specified window, recording 
+  all changes between snapshots, which is then replayed at the time of
+  restore. This enables recovery to any point in time within the window,
+  meeting Recovery Point Objectives (RPOs) as low as 1 minute.  
+
+We don't recommend enabling backup for development and test
+environments. For staging and production environments, we recommend
+developing automated deployment templates that include the
+recommendations described in this page. 
+
+{+service+} Features and Recommendations for Backups
+----------------------------------------------------
+
+Features
+~~~~~~~~
+
+|service| provides fully-managed backups of the data, including
+point-in-time data recovery and consistent, cluster-wide snapshots of
+all {+clusters+}, including sharded {+clusters+}. |service| Cloud
+Backups storage is separate from the |service| instances and uses the
+native snapshot functionality of the {+cluster+}'s cloud service
+provider.  
+
+.. list-table:: 
+   :widths: 20 80 
+   :stub-columns: 1
+
+   * - |service| cloud backups
+     - This allows you to utilize the native snapshot functionality
+       of your {+cluster+}'s cloud service provider and store backups
+       separately from the your |service| instances. Benefits include a
+       strong default backup retention schedule of 12 months, full
+       flexibility to customize snapshot and retention schedules, and
+       the ability to set different snapshot frequencies (such as hourly
+       for recovery, weekly or monthly for long-term retention) to meet
+       industry regulations. You can access your backup data instantly,
+       which is useful for auditing, compliance, or data recovery
+       purposes and also run queries directly against the backup data,
+       saving time and resources.  
+
+   * - Continuous cloud backups
+     - This provides a customizable automated backup schedule and Point
+       In Time (PIT) recovery, which allows you to recover back to a
+       any timestamp. This allows you to recover your data to the exact
+       moment (a point in time) right before any failure or event, like
+       a cyber attack. You can also set a customized restore window to
+       dictate how many days you  would like to be able to restore back
+       to a specific point in time. In |service|, you can choose from
+       four snapshot frequencies: hourly, daily, weekly, and monthly,
+       each with its own retention period. 
+
+   * - Multi-region snapshot distribution
+     - This allows you to add multiple region snapshot distribution with
+       |service| cloud backups and increase resilience by distributing
+       backup snapshots and oplogs across geographic regions instead of
+       just storing them in their primary region. You can meet
+       compliance requirements of storing backups in different, air
+       gapped geographical locations to ensure disaster recovery in case
+       of regional outages. 
+
+   * - Backup compliance policy 
+     - This feature enables you to further secure business critical data
+       by preventing all snapshots and oplogs stored in |service| from
+       being modified or deleted for a predefined retention period
+       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.  
+
+Recommendations for Backup Strategy
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You must align your backup strategy with specific Recovery Point
+Objectives (RPO) and Recovery Time Objectives (RTO) to meet business
+continuity requirements, particularly for critical applications where
+near-instant RPO and rapid recovery times are crucial. RPO defines the
+maximum acceptable amount of data loss during an incident, while RTO 
+defines how quickly your application must recover. Since data varies in
+importance, you must evaluate RPO and RTO for each application
+individually. For example, any mission-critical data will likely have 
+different requirements than clickstream analytics. Your requirements
+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.
+
+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
+point in time. 
+
+Recommendations for Backup Snapshots 
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+|service| provides predefined backup snapshot schedules including
+frequency of snapshots, and retention period. Retaining backup snapshots
+for long periods can be costly. We recommend building automated
+deployment templates that meet your requirements based on the size and
+criticality of the data and the environment (development, test, staging,
+production). For frequency and retention of snapshots, we recommend
+the following: 
+
+.. list-table:: 
+   :widths: 10 15 20 45 10
+   :header-rows: 1
+
+   * - Tier
+     - RTO 
+     - RPO
+     - Recommended Frequency and Retention
+     - Total Number of Snapshots
+
+   * - Tier 1 
+     - 30 minutes 
+     - Near zero (within 7 days)
+     - | **Hourly**: Every 12 hours, retain for 7 days = 14 snapshots
+       | **Daily**: Once a day, retain for 7 days = 7 snapshots
+       | **Weekly**: Saturday, retain for 4 weeks = 4 snapshots
+       | **Monthly**: Last day of month, retain for 3 months = 6 snapshots
+     - 31
+
+   * - Tier 2 
+     - 12 hours 
+     - Near zero (within 7 days)
+     - | **Daily**: Once a day, retain for 7 days = 7 snapshots
+       | **Weekly**: Saturday, retain for 4 weeks = 4 snapshots
+       | **Monthly**: Last day of month, retain for 3 months = 3 snapshots
+     - 14
+
+   * - Tier 3 
+     - 3 days 
+     - Near zero (within 2 days)
+     - | **Daily**: Once a day, retain for 7 days = 7 snapshots
+       | **Weekly**: Saturday, retain for 4 weeks = 4 snapshots
+       | **Monthly**: Last day of month, retain for 3 months = 3 snapshots
+     - 14
+
+We recommend Queryable Backup Snapshot options when defining automation
+templates. Queryable Backups allow you to access your backup data
+instantly and run queries directly against the backup data, including on
+data as it existed at the time of the backup. Queryable backups also
+maintain the same security and access controls as your live {+clusters+},
+ensuring that sensitive data is protected. In some cases, we recommend
+adjusting backup snapshot frequencies and retentions to save money if
+queryable backup strategies suffice.  
+
+Recommendations for Backup Distribution 
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-{+service+} Features and Best Practices for Backups
----------------------------------------------------
+|service| provides options for backup locations. To further enhance
+resilience, for staging and production environments only, we recommend
+distributing backups in local region and to external disaster recovery
+region, ensuring data recovery even during regional outages. For an
+|service| {+cluster+} in three regions, multi-region Snapshot
+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 
+{+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
+critical workloads might require multiple copies of snapshots in various
+locations.
 
-Content here
+Recommendations for Backup Compliance Policy 
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We recommend enforcing |service|'s Backup Compliance Policy to prevent
+unauthorized modifications or deletions of backups, thereby maintaining
+data integrity and supporting robust disaster recovery.  
+
+Recommendations for PIT Recovery
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+|service|'s fully managed, customizable Cloud Backups and Continuous
+Cloud Backups enable precise Point In Time (PIT) recovery, minimizing
+data loss during failures. |service| can quickly recover to the exact
+timestamp before a failure event, giving you at least a one minute
+:abbr:`RPO (Recovery Point Objective)` and an :abbr:`RTO (Recovery Time
+Objective)` of less than 15 minutes when utilizing optimized restores,
+even in the event of the outage of the primary region. Recovery times
+can vary due to cloud provider disk warming and which point in time you
+are restoring to. If you can be flexible in your requirements for
+recovery, we recommend designing templates that identify the sweet spot
+between reasonable recovery options and cost. 
+
+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
+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
+prevent overspending. By implementing these strategies, you can
+effectively manage costs while maintaining secure and reliable backups. 
 
 Examples
 --------
 
-The following examples <perform this action> using |service|
+The following examples enable backup and restore operations using |service|
 :ref:`tools for automation <arch-center-automation>`.
 
-These examples also apply other recommended configurations, including:
+These examples apply only for staging and production environments where
+backup is enabled for the {+cluster+}.
 
 .. tabs::
 
-   .. tab:: Dev and Test Environments
-      :tabid: devtest
+   .. tab:: CLI
+      :tabid: cli
 
-      .. include:: /includes/shared-settings-clusters-devtest.rst
+      Run the following command take a backup snapshot for the {+cluster+}
+      named myDemo and retain the snapshot for 7 days:
 
-   .. tab:: Staging and Prod Environments
-      :tabid: stagingprod
+      .. include:: /includes/examples/cli-example-backup-take-snapshot.rst
 
-      .. include:: /includes/shared-settings-clusters-stagingprod.rst
+      Enable backup compliance policy for your project with a
+      designated, authorized user named ``john doe`` who alone can turn
+      off this protection after completing a verification process with
+      MongoDB support. 
 
-.. tabs::
+      .. include:: /includes/examples/cli-example-backup-compliance-policy-enable.rst
 
-   .. tab:: CLI
-      :tabid: cli
+      Run the following command to create a compliance policy for
+      scheduled backup snapshots that enforces the number of times
+      (``2``) snapshots must be taken every month and the duration
+      (``2`` months) for retaining the snapshots. 
 
-      Content here
+      .. include:: /includes/examples/cli-example-backup-compliance-policy-schedule.rst
 
    .. tab:: Terraform
       :tabid: Terraform
+ 
+      The following examples demonstrate how to configure backups during
+      deployment. Before you can create resources with Terraform,
+      you must:  
+
+      - :ref:`Create your paying organization <configure-paying-org>`
+        and :ref:`create an API key <atlas-admin-api-access>` for the
+        paying organization. Store your API key as environment variables
+        by running the following command in the terminal: 
+
+        .. code-block::
+
+           export MONGODB_ATLAS_PUBLIC_KEY="<insert your public key here>"
+           export MONGODB_ATLAS_PRIVATE_KEY="<insert your private key here>"
+
+      - `Install Terraform <https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli>`__.
+
+      Common Files 
+      ~~~~~~~~~~~~
+
+      You must create the following files for each example. Place the
+      files for each example in their own directory. Change the IDs and
+      names to use your values. Then run the commands to initialize
+      Terraform, view the Terraform plan, and apply the changes. 
+
+      variables.tf 
+      ````````````
+
+      .. include:: /includes/examples/tf-example-backup-variables.rst
+
+
+      Configure Backup Schedule for the {+Cluster+} 
+      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+      Use the following to configure a backup schedule for the
+      {+cluster+}. 
+
+      main.tf 
+      ```````
+
+      .. include:: /includes/examples/tf-example-backup-snapshot-schedule.rst
+
+      Configure Backup and PIT Restore for the {+Cluster+}
+      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-      Content here
+      Use the following to configure cloud backup snapshot and PIT restore
+      job.
 
+      main.tf 
+      ```````
+      
+      .. include:: /includes/examples/tf-example-backup-snapshot-pit-restore.rst

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

@@ -0,0 +1,8 @@
+.. code-block:: shell 
+   :copyable: true 
+
+   atlas backups compliancePolicy enable \ 
+     --projectId 67212db237c5766221eb6ad9 \
+     --authorizedEmail [email protected] \
+     --authorizedUserFirstName john \
+     --authorizedUserLastName doe

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

@@ -0,0 +1,9 @@
+.. code-block:: shell 
+   :copyable: true 
+
+   atlas backups compliancePolicy policies scheduled create \ 
+     --projectId 67212db237c5766221eb6ad9 \
+     --frequencyInterval 2 \
+     --frequencyType monthly \
+     --retentionValue 2 \
+     --retentionUnit months

source/includes/examples/cli-example-backup-take-snapshot.rst

@@ -0,0 +1,4 @@
+.. code-block:: shell 
+   :copyable: true 
+
+   atlas backups snapshots create myDemo --desc "my backup snapshot" --retention 7