Backup and restore in Azure Cosmos DB for PostgreSQL

  • Article

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

Azure Cosmos DB for PostgreSQL automatically creates 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.

Backups

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

Backup files can't be exported. They may only be used for restore operations in Azure Cosmos DB for PostgreSQL.

Backup storage cost

For current backup storage pricing, see the Azure Cosmos DB for PostgreSQL pricing page.

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 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 might need to open a support request to restore the cluster to a point that is earlier than the latest failover time. In addition to high availability (HA), maintenance and compute / storage scaling operations use failovers to minimize downtime during these operations.

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 isn't enabled on the cluster), you might 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 cluster, all nodes that belong to the cluster are deleted and can't be recovered. To protect cluster resources, post deployment, from accidental deletion or unexpected changes, administrators can leverage management locks.

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.

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.

In most cases, cluster restore takes up to 1 hour.

Next steps