Merge pull request #252027 from niklarin/geo-backup

v-dirichards · web-flow · commit f6ba5bafe3ef · 2023-09-27T10:36:20.000-05:00
Geo-backup additions
diff --git a/articles/cosmos-db/postgresql/concepts-backup.md b/articles/cosmos-db/postgresql/concepts-backup.md
@@ -5,17 +5,17 @@ ms.author: nlarin
 author: niklarin
 ms.service: cosmos-db
 ms.subservice: postgresql
-ms.custom: ignite-2022
+ms.custom: ignite-2022, references_regions
 ms.topic: conceptual
-ms.date: 07/10/2023
+ms.date: 09/17/2023
 ---
 
 # Backup and restore in Azure Cosmos DB for PostgreSQL
 
 [!INCLUDE [PostgreSQL](../includes/appliesto-postgresql.md)]
 
 Azure Cosmos DB for PostgreSQL automatically creates
-backups of each node and stores them in locally redundant storage. Backups can
+backups of each node in a cluster. Backups can
 be used to restore your cluster to a specified time - point-in-time restore (PITR).
 Backup and restore are an essential part of any business continuity strategy
 because they protect your data from accidental corruption or deletion.
@@ -29,13 +29,49 @@ server to any point in time within the retention period. (The retention period
 is currently 35 days for all clusters.) All backups are encrypted using
 AES 256-bit encryption.
 
-In Azure regions that support availability zones, backup snapshots and WAL files are stored
-in three availability zones. As long as at least one availability zone is
-online, the cluster is restorable.
-
 Backup files can't be exported. They may only be used for restore operations
 in Azure Cosmos DB for PostgreSQL.
 
+### Backup redundancy
+
+Azure Cosmos DB for PostgreSQL supports the following backup redundancy options.
+
+* Same region backup
+    * Zone-redundant backup storage: This option is automatically chosen for regions that support availability zones. When the backups are stored in zone-redundant backup storage, in addition to multiple copies of data stored within the availability zone where each cluster's node is hosted, the data is also replicated to other availability zones.
+
+    * Locally redundant backup storage: This option is automatically chosen for regions that don't support availability zones. When the backups are stored in locally redundant backup storage, multiple copies of backups are stored in the same region.
+
+* Cross-region backup (in preview)
+    * Geo-redundant backup storage: You can choose this option at the time of cluster creation. When the backups are stored in another region, in addition to three copies of data stored within the region where your cluster is hosted, the data is replicated to another region.
+
+Geo-redundant backup is supported in the following Azure regions.
+
+| Cluster's region      | Geo-backup stored in           |
+|-----------------------|--------------------------------|
+| Canada Central        | Canada East                    |
+| Central US            | East US 2                      |
+| East Asia             | Southeast Asia                 |
+| East US               | West US                        |
+| East US 2             | Central US                     |
+| Japan East            | Japan West                     |
+| Japan West            | Japan East                     |
+| North Central US      | South Central US               |
+| North Europe          | West Europe                    |
+| South Central US      | North Central US               |
+| Southeast Asia        | East Asia                      |
+| Switzerland North     | Switzerland West               |
+| Switzerland West      | Switzerland North              |
+| West Central US       | West US 2                      |
+| West Europe           | North Europe                   |
+| West US               | East US                        |
+| West US 2             | West Central US                |
+
+> [!IMPORTANT]
+> Geo-redundant backup and restore in Azure Cosmos DB for PostgreSQL is currently in preview.
+> This preview version is provided without a service level agreement, and it's not recommended
+> for production workloads. Certain features might not be supported or might have constrained 
+> capabilities.
+
 ### Backup storage cost
 
 For current backup storage pricing, see the Azure Cosmos DB for PostgreSQL
@@ -44,7 +80,7 @@ For current backup storage pricing, see the Azure Cosmos DB for PostgreSQL
 ## Restore
 
 You can restore a cluster to any point in time within
-the last 35 days.  Point-in-time restore is useful in multiple scenarios. For
+the last 35 days. Point-in-time restore is useful in multiple scenarios. For
 example, when a user accidentally deletes data, drops an important table or
 database, or if an application accidentally overwrites good data with bad data.
 
@@ -53,7 +89,9 @@ database, or if an application accidentally overwrites good data with bad data.
 > open a support request to restore the cluster to a point that is earlier
 > than the latest failover time.  
 
-When all nodes are up and running, you can restore cluster without any data loss. In an extremely rare case of a node experiencing a catastrophic event (and [high availability](./concepts-high-availability.md) isn't enabled on the cluster), you may lose up to 5 minutes of data.
+For same-region restore, when all nodes are up and running, you can restore cluster without any data loss. In an extremely rare case of a node experiencing a catastrophic event (and [high availability](./concepts-high-availability.md) isn't enabled on the cluster), you may lose up to 5 minutes of data.
+
+On clusters with geo-backup enabled, restore can be performed in the remote region or in the same region where cluster is located.
 
 > [!IMPORTANT]
 > Deleted clusters can't be restored. If you delete the
@@ -62,7 +100,7 @@ When all nodes are up and running, you can restore cluster without any data loss
 > accidental deletion or unexpected changes, administrators can leverage
 > [management locks](../../azure-resource-manager/management/lock-resources.md).
 
-The restore process creates a new cluster in the same Azure region,
+The restore process creates a new cluster in the same or remote Azure region,
 subscription, and resource group as the original. The cluster has the
 original's configuration: the same number of nodes, number of vCores, storage
 size, user roles, PostgreSQL version, and version of the Citus extension.
@@ -75,4 +113,5 @@ In most cases, cluster restore takes up to 1 hour.
 
 * See the steps to [restore a cluster](howto-restore-portal.md)
   in the Azure portal.
+* See [backup and restore limits and limitations](./reference-limits.md#backup-and-restore).
 * Learn about [Azure availability zones](../../availability-zones/az-overview.md).
diff --git a/articles/cosmos-db/postgresql/howto-read-replicas-portal.md b/articles/cosmos-db/postgresql/howto-read-replicas-portal.md
@@ -37,7 +37,7 @@ To create a read replica, follow these steps:
 
 4. Under **Cluster name**, enter a name for the read replica.
 
-5. Select a value from the **Location (preview)** drop-down.
+5. Select a value from the **Location** drop-down.
 
 6. Select **OK**.
 
@@ -52,6 +52,21 @@ After the read replica is created, you can see it listed on the **Replicate data
 > replica setting to an equal or greater value. This action helps the replica
 > keep up with any changes made to the master.
 
+## Promote a read replica
+
+To [promote a cluster read replica](./concepts-read-replicas.md#replica-promotion-to-independent-cluster) to an independent read-write cluster, follow these steps:
+
+1. Select the read replica you would like to promote in the portal. 
+
+2. On the cluster sidebar, under **Cluster management**, select
+   **Replicate data globally**.
+
+3. On the **Replicate data globally** page, find the read replica in the list of clusters under the map and click the promote icon. 
+
+4. On the **Promote \<cluster name>** screen, double check the read replica's name, confirm that you understand that promotion is irreversible by setting the checkbox, and select **Promote**.
+
+After the read replica is promoted, it becomes an independent readable and writable cluster with the same connection string. 
+
 ## Delete a primary cluster
 
 To delete a primary cluster, you use the same steps as to delete a
diff --git a/articles/cosmos-db/postgresql/howto-restore-portal.md b/articles/cosmos-db/postgresql/howto-restore-portal.md
@@ -1,36 +1,68 @@
 ---
 title: Restore - Azure Cosmos DB for PostgreSQL - Azure portal
 description: See how to perform restore operations in Azure Cosmos DB for PostgreSQL through the Azure portal.
-ms.author: jonels
-author: jonels-msft
+ms.author: nlarin
+author: niklarin
 ms.service: cosmos-db
 ms.subservice: postgresql
-ms.custom: ignite-2022
+ms.custom: ignite-2022, references_regions
 ms.topic: how-to
-ms.date: 06/12/2023
+ms.date: 09/17/2023
 ---
 
-# Point-in-time restore of a cluster in Azure Cosmos DB for PostgreSQL
+# Backup and point-in-time restore of a cluster in Azure Cosmos DB for PostgreSQL
 
 [!INCLUDE [PostgreSQL](../includes/appliesto-postgresql.md)]
 
-This article provides step-by-step procedures to perform [point-in-time
+> [!IMPORTANT]
+> Geo-redundant backup and restore in Azure Cosmos DB for PostgreSQL is currently in preview.
+> This preview version is provided without a service level agreement, and it's not recommended
+> for production workloads. Certain features might not be supported or might have constrained 
+> capabilities.
+
+This article provides step-by-step procedures to select backup type, to check type of backup enabled on a cluster, and to perform [point-in-time
 recoveries](concepts-backup.md#restore) for a
 cluster using backups. You can restore either to the earliest backup or to
 a custom restore point within your retention period.
 
+> [!NOTE]
+> While cluster backups are always stored for 35 days, you may need to 
+> open a support request to restore the cluster to a point that is earlier
+> than the latest failover time. 
+
+## Select type of cluster backup
+Enabling geo-redundant backup is possible during cluster creation on the **Scale** screen that can be accessed on the **Basics** tab. Click the **Save** button to apply your selection. 
+
+> [!NOTE]
+> Geo-redundant backup can be enabled only during cluster creation. 
+> You can't disable geo-redundant backup once cluster is created.
+
+## Confirm type of backup
+To check what type of backup is enabled on a cluster, follow these steps:
+
+1. In the [Azure portal](https://portal.azure.com/), select an existing Azure Cosmos DB for PostgreSQL cluster.
+1. On the **Overview** page, check **Backup** field in the **Essentials** section.
+
+The **Backup** field values can be **Locally redundant** or **Zone redundant** for the same region cluster backup or **Geo-redundant** for the backup stored in another Azure region.
+
 ## Restore to the earliest restore point
 
 Follow these steps to restore your cluster to its
 earliest existing backup.
 
-1.  In the [Azure portal](https://portal.azure.com/), from the **Overview** page of the cluster you want to restore, select **Restore**.
+1. In the [Azure portal](https://portal.azure.com/), from the **Overview** page of the cluster you want to restore, select **Restore**.
 
 1. On the **Restore** page, select the **Earliest** restore point, which is shown.
 
-1. Provide a new cluster name in the **Restore to new cluster** field. The subscription, resource group, and location fields aren't editable.
+1. Provide a new cluster name in the **Restore to new cluster** field. The subscription and resource group fields aren't editable.
 
-1. Select **OK**. A notification shows that the restore operation is initiated.
+1. If cluster has geo-redundant backup enabled, select remote or same region for restore in the **Location** field. On clusters with zone-redundant and locally redundant backup, location field isn't editable.
+
+1. Select **Next**. 
+
+1. (optional) Make data encryption selection for restored cluster on the **Encryption (preview)** tab.
+
+1. Select **Create**. A notification shows that the restore operation is initiated.
 
 1. When the restore completes, follow the [post-restore tasks](#post-restore-tasks).
 
@@ -39,13 +71,19 @@ earliest existing backup.
 Follow these steps to restore your cluster to a date
 and time of your choosing.
 
-1.  In the [Azure portal](https://portal.azure.com/), from the **Overview** page of the cluster you want to restore, select **Restore**.
+1. In the [Azure portal](https://portal.azure.com/), from the **Overview** page of the cluster you want to restore, select **Restore**.
 
 1. On the **Restore** page, choose **Custom restore point**.
 
-1. Select a date and provide a time in the date and time fields, and enter a cluster name in the **Restore to new cluster** field. The other fields aren't editable.
- 
-1. Select **OK**. A notification shows that the restore operation is initiated.
+1. Select a date and provide a time in the date and time fields, and enter a cluster name in the **Restore to new cluster** field. The subscription and resource group fields aren't editable.
+
+1. If cluster has geo-redundant backup enabled, select remote or same region for restore in the **Location** field. On clusters with zone-redundant and locally redundant backup, location field isn't editable.
+
+1. Select **Next**. 
+
+1. (optional) Make data encryption selection for restored cluster on the **Encryption (preview)** tab.
+
+1. Select **Create**. A notification shows that the restore operation is initiated.
 
 1. When the restore completes, follow the [post-restore tasks](#post-restore-tasks).
 
@@ -54,8 +92,8 @@ and time of your choosing.
 After a restore, you should do the following to get your users and applications
 back up and running:
 
-* If the new server is meant to replace the original server, redirect clients
-  and client applications to the new server
+* If the new cluster is meant to replace the original cluster, redirect clients
+  and client applications to the new cluster.
 * Ensure appropriate [networking settings for private or public access](./concepts-security-overview.md#network-security) are in place for
   users to connect. These settings aren't copied from the original cluster.
 * Ensure appropriate [logins](./howto-create-users.md) and database level permissions are in place.
@@ -65,4 +103,5 @@ back up and running:
 
 * Learn more about [backup and restore](concepts-backup.md) in
   Azure Cosmos DB for PostgreSQL.
+* See [backup and restore limits and limitations](./reference-limits.md#backup-and-restore).
 * Set [suggested alerts](./howto-alert-on-metric.md#suggested-alerts) on clusters.
diff --git a/articles/cosmos-db/postgresql/product-updates.md b/articles/cosmos-db/postgresql/product-updates.md
@@ -7,7 +7,7 @@ ms.custom: mvc, references_regions
 ms.service: cosmos-db
 ms.subservice: postgresql
 ms.topic: conceptual
-ms.date: 09/18/2023
+ms.date: 09/25/2023
 ---
 
 # Product updates for Azure Cosmos DB for PostgreSQL
@@ -23,6 +23,8 @@ Updates that don’t directly affect the internals of a cluster are rolled out g
 Updates that change cluster internals, such as installing a [new minor PostgreSQL version](https://www.postgresql.org/developer/roadmap/), are delivered to existing clusters as part of the next [scheduled maintenance](concepts-maintenance.md) event. Such updates are available immediately to newly created clusters.
 
 ### September 2023
+* Preview: Geo-redundant backup and restore
+    * Learn more about [backup and restore Azure Cosmos DB for PostgreSQL](./concepts-backup.md)
 * Preview: [32 TiB storage per node for multi-node configurations](./resources-compute.md#multi-node-cluster) is now available in all supported regions.
     * See [how to maximize IOPS on your cluster](./resources-compute.md#maximum-iops-for-your-compute--storage-configuration).
 * General availability: Azure Cosmos DB for PostgreSQL is now available in Australia Central, Canada East, and Qatar Central.
@@ -136,6 +138,7 @@ might have constrained capabilities.  For more information, see
 [Supplemental Terms of Use for Microsoft Azure
 Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/)
 
+* [Geo-redundant backup and restore](./concepts-backup.md#backup-redundancy)
 * [32 TiB storage per node in multi-node clusters](./resources-compute.md#multi-node-cluster)
 * [Azure Active Directory (Azure AD) authentication](./concepts-authentication.md#azure-active-directory-authentication-preview)
 * [Azure CLI support for Azure Cosmos DB for PostgreSQL](/cli/azure/cosmosdb/postgres)
diff --git a/articles/cosmos-db/postgresql/reference-limits.md b/articles/cosmos-db/postgresql/reference-limits.md
@@ -62,7 +62,7 @@ be scaled down (decreased).
 
 ### Storage size
 
-Up to 16 TiB of storage is supported on coordinator and worker nodes in multi-node configuration. Up to 2 TiB of storage is supported for single node configurations. See [the available storage options and IOPS calculation](resources-compute.md)
+Up to 32 TiB of storage is supported on coordinator and worker nodes in multi-node configuration. Up to 2 TiB of storage is supported for single node configurations. See [the available storage options and IOPS calculation](resources-compute.md)
 for various node and cluster sizes.
 
 ## Compute
@@ -85,6 +85,7 @@ currently **not supported**:
 * PostgreSQL 11 support
 * Read replicas
 * High availability
+* Geo-redundant backup
 * The [azure_storage](howto-ingest-azure-blob-storage.md) extension
 
 ## Authentication
@@ -104,6 +105,17 @@ with an error.
 
 By default this database is called `citus`. Azure Cosmos DB for PostgreSQL supports custom database names at cluster provisioning time only.  
 
+## Backup and restore
+
+### Geo-redundant backup and restore (preview)
+* Geo-redundant backup can be enabled only during cluster creation.
+    * You can enable geo-redundant backup when you perform a cluster restore.
+    * You can enable geo-redundant backup when you [promote a cluster read-replica to an independent cluster](./howto-read-replicas-portal.md#promote-a-read-replica).
+* Geo-redundant backup can't be enabled on single node clusters with [burstable compute](./concepts-burstable-compute.md).
+* Geo-redundant backup can't be disabled once cluster is created.
+* [Customer managed key (CMK)](./concepts-customer-managed-keys.md) isn't supported for clusters with geo-redundant backup enabled.
+* Azure Cosmos DB for PostgreSQL cluster with geo-redundant backup enabled can't have a [cluster read replica](./concepts-read-replicas.md) in the region where geo-redundant backup is stored.
+
 ## Next steps
 
 * Learn how to [create a cluster in the
