Improving Postgres Server Backup Solution

Question

What are some ways to improve upon the built-in backup functions of Postgres flexible server to ensure that backups are recoverable in case the server is deleted? It's important to have a separate backup that is protected against accidental deletion, with a defined retention period.

Answer 1

Hi mungi sai meghavardhan •,

Welcome to Microsoft Q&A forum.

As I understand, you want to know about the Azure Database for PostgreSQL Flexible server backup options in case of accidental deletion.

Azure Database for PostgreSQL flexible server automatically creates server backups and stores them on the region's zone redundant storage (ZRS). Backups can restore your server to any point within the backup retention period. The default backup retention period is seven days. The retention can be optionally configured for up to 35 days. All backups are encrypted using AES 256-bit encryption. See Backups for more details.

High availability feature provisions physically separate primary and standby replica with the same zone or across zones depending on the deployment model. For more information, see high availability concepts documentation. You may choose to enable high availability at the time of Azure Database for PostgreSQL flexible server instance creation or after the creation.

In the case of a region-wide disaster, Azure can provide protection from regional or large geography disasters with disaster recovery by making use of another region. For more information on Azure disaster recovery architecture, see Azure to Azure disaster recovery architecture.

Flexible server provides features that protect data and mitigates downtime for your mission-critical databases during planned and unplanned downtime events. Built on top of the Azure infrastructure that offers robust resiliency and availability, flexible server offers business continuity features that provide fault-protection, address recovery time requirements, and reduce data loss exposure. As you architect your applications, you should consider the downtime tolerance - the recovery time objective (RTO), and data loss exposure - the recovery point objective (RPO). For example, your business-critical database requires stricter uptime than a test database.

If your server is configured with geo-redundant backup, you can perform geo-restore in the paired region. A new server is provisioned and recovered to the last available data that was copied to this region.

You can also use cross region read replicas. In the event of region failure you can perform disaster recovery operation by promoting your read replica to be a standalone read-writeable server. RPO is expected to be up to 5 minutes (data loss possible) except in the case of severe regional failure when the RPO can be close to the replication lag at the time of failure.

For more information on unplanned downtime mitigation and recovery after regional disaster, see Unplanned downtime mitigation.

Read more here: https://learn.microsoft.com/en-us/azure/reliability/reliability-postgresql-flexible-server

Hope this helps.

Thanks