Edit

Backup and point-in-time restore of a cluster in Azure Cosmos DB for PostgreSQL

  • Article

APPLIES TO: Azure Cosmos DB for PostgreSQL (powered by the Citus database extension to PostgreSQL)

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 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 might need to open a support request to restore the cluster to a point that is earlier than the latest failover time. Maintenance and compute / storage scaling operations use failovers to minimize downtime during these operations.

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 or cluster restore. 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, select an existing Azure Cosmos DB for PostgreSQL cluster.
  2. 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, from the Overview page of the cluster you want to restore, select Restore.

  2. On the Restore page, select the Earliest restore point, which is shown.

  3. Provide a new cluster name in the Restore to new cluster field. The subscription and resource group fields aren't editable.

  4. 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.

  5. Set Geo-redundant backup checkbox for geo-redundant backup for the restored cluster to be stored in another Azure region.

  6. Select Next.

  7. (optional) Make data encryption selection for restored cluster on the Encryption tab.

  8. Select Create. A notification shows that the restore operation is initiated.

  9. When the restore completes, follow the post-restore tasks.

Restore to a custom restore point

Follow these steps to restore your cluster to a date and time of your choosing.

  1. In the Azure portal, from the Overview page of the cluster you want to restore, select Restore.

  2. On the Restore page, choose Custom restore point.

  3. 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.

  4. 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.

  5. Set Geo-redundant backup checkbox for geo-redundant backup for the restored cluster to be stored in another Azure region.

  6. Select Next.

  7. (optional) Make data encryption selection for restored cluster on the Encryption tab.

  8. Select Create. A notification shows that the restore operation is initiated.

  9. When the restore completes, follow the post-restore tasks.

Post-restore tasks

After a restore, you should do the following to get your users and applications back up and running:

  • 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 are in place for users to connect. These settings aren't copied from the original cluster.
  • Ensure appropriate logins and database level permissions are in place.
  • Configure alerts, as appropriate.

Next steps