Merge pull request #241395 from niklarin/backup

Backup/restore updates

Author: PMEds28

articles/cosmos-db/postgresql/concepts-backup.md

@@ -1,13 +1,13 @@
 ---
 title: Backup and restore – Azure Cosmos DB for PostgreSQL
 description: Protecting data from accidental corruption or deletion
-ms.author: jonels
-author: jonels-msft
+ms.author: nlarin
+author: niklarin
 ms.service: cosmos-db
 ms.subservice: postgresql
 ms.custom: ignite-2022
 ms.topic: conceptual
-ms.date: 04/14/2021
+ms.date: 07/10/2023
 ---
 
 # Backup and restore in Azure Cosmos DB for PostgreSQL
@@ -16,19 +16,20 @@ ms.date: 04/14/2021
 
 Azure Cosmos DB for PostgreSQL automatically creates
 backups of each node and stores them in locally redundant storage. Backups can
-be used to restore your cluster to a specified time.
+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.
 
 ## Backups
 
-At least once a day, Azure Cosmos DB for PostgreSQL takes snapshot backups of
-data files and the database transaction log. The backups allow you to restore a
+Automated process performs backup of each Azure Cosmos DB for PostgreSQL node from the moment your cluster is provisioned and throughout cluster's lifecycle. Azure Cosmos DB for PostgreSQL takes periodic disk snapshots and combines it with the node's [WAL files](https://www.postgresql.org/docs/current/wal-intro.html) streaming to Azure blob storage. 
+
+The backups allow you to restore a
 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 are stored
+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.
 
@@ -47,6 +48,13 @@ 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.
 
+> [!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.  
+
+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.
+
 > [!IMPORTANT]
 > Deleted clusters can't be restored. If you delete the
 > cluster, all nodes that belong to the cluster are deleted and can't
@@ -59,11 +67,9 @@ 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.
 
-Firewall settings and PostgreSQL server parameters are not preserved from the
-original cluster, they are reset to default values. The firewall will
-prevent all connections. You will need to manually adjust these settings after
-restore. In general, see our list of suggested [post-restore
-tasks](howto-restore-portal.md#post-restore-tasks).
+Networking settings aren't preserved from the original cluster, they're reset to default values. You'll need to manually adjust these settings after restore to allow access to the restored cluster. In general, see our list of suggested [post-restore tasks](howto-restore-portal.md#post-restore-tasks).
+
+In most cases, cluster restore takes up to 1 hour.
 
 ## Next steps
 

articles/cosmos-db/postgresql/howto-restore-portal.md

@@ -7,7 +7,7 @@ ms.service: cosmos-db
 ms.subservice: postgresql
 ms.custom: ignite-2022
 ms.topic: how-to
-ms.date: 01/30/2023
+ms.date: 06/12/2023
 ---
 
 # Point-in-time restore of a cluster in Azure Cosmos DB for PostgreSQL
@@ -19,9 +19,6 @@ 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.
 
-> [!IMPORTANT]
-> If the **Restore** option isn't present for your cluster, open an Azure support request to restore your cluster.
-
 ## Restore to the earliest restore point
 
 Follow these steps to restore your cluster to its
@@ -59,12 +56,10 @@ back up and running:
 
 * If the new server is meant to replace the original server, redirect clients
   and client applications to the new server
-* Ensure an appropriate server-level firewall is in place for
-  users to connect. These rules aren't copied from the original cluster.
-* Adjust PostgreSQL server parameters as needed. The parameters aren't copied
-  from the original cluster.
-* Ensure appropriate logins and database level permissions are in place.
-* Configure alerts, as appropriate.
+* 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.
+* Configure [alerts](./howto-alert-on-metric.md#suggested-alerts), as appropriate.
 
 ## Next steps