Backup and Disaster Recovery of Azure PostgreSQL Database

Author – Prashant Pawar, Associate Cloud Engineer

Data loss can happen at any moment, at any scale. Most of the companies that suffered significant data loss in the past end up going out of business with in few months of that incident. That’s why more and more organization are realizing the importance of keeping their mission critical data backed up and saved at all the times. The purpose of the backup is to create a copy of the data which can be recovered in case of any unplanned event leading to hampering the continuity of the Service. Microsoft Azure offers Backup and Disaster Recovery solutions for PostgreSQL Database to ensure Business Continuity for the Service workloads.

In this blog, we’ll take a look at what features Microsoft Azure offers for PostgreSQL database backup and disaster recovery environment.

Steps to configure backup

Azure Database for PostgreSQL servers are backed up periodically to enable Restore features. Using this feature, you may restore the server and all its databases to an earlier point-in-time, on a new server.

You make the choice between configuring your server for either locally redundant backups or geographically redundant backups at server creation. This window is also where you select the Backup Retention Period – how long (in number of days) you want the server backups stored for.

Sign into the Azure portal.
Search Azure Database for PostgreSQL server.
Select the Single server deployment option.
Provide the subscription, resource group, and name of the new server.
In server configuration, select General purpose or Memory optimized for Geo redundant backup and read replicas.

(Note: After a server is created, the kind of redundancy it has, geographically redundant vs locally redundant, can’t be switched.)

Click OK to confirm the change.

The backup retention period governs how far back in time a point-in-time restore can be retrieved, since it’s based on backups available.

Point-in-time restore

Azure Database for PostgreSQL allows you to restore the server back to a point-in-time and into to a new copy of the server.

The following steps restore the sample server to a point-in-time:

In the Azure portal, select your Azure Database for PostgreSQL server.
In the toolbar of the server’s Overview page, select Restore.

Fill out the Restore form with the required information.
Click OK to restore the server to restore to a point-in-time.
Once the restore finishes, locate the new server that is created to verify the data was restored as expected.

Geo restore

If you configured your server for geographically redundant backups, a new server can be created from the backup of that existing server in any region that Azure Database for PostgreSQL is available.

Select the Create a resource button (+) in the upper-left corner of the portal. Select Databases > Azure Database for PostgreSQL.
Select the Single server deployment option.
Provide the subscription, resource group, and name of the new server.
Select Backup as the Data source. This action loads a drop-down that provides a list of servers that have geo redundant backups enabled.

Select the Backup drop-down.
Fill out the rest of the form with your preferences. You can select any Location. Changing Pricing Tier (Basic, General Purpose, or Memory Optimized) or Storage size during restore is not supported.
Select Review + create to review your selections.
Select Create to provision the server. This operation may take a few minutes.

Steps to create read replica

Select an existing Azure Database for PostgreSQL server to use as the master server.
On the server sidebar, under SETTINGS, select Replication.
Select Add Replica.

Enter a name for the read replica.
Select a location for the replica. The default location is the same as the master server’s.
Select OK to confirm the creation of the replica.

After the read replica is created, it can be viewed from the Replication window

Stop replication

You can stop replication between a master server and a read replica. To stop replication between a master server and a read replica from the Azure portal, follow these steps: