Backup and restore are key pillars for business continuity and disaster recovery offerings for Azure Database for PostgreSQL Flexible Server. We’re excited to announce new features including Fast Restore, Geo Restore and Custom Restore Points to allow you more fine-grained control on your DR plan to achieve the RPO^ and RTO^^ objectives. In this post we’ll share an overview of each of these new features. Let’s get started.
1. Fast Restore
Point-in-time restore (PITR) is critical for disaster recovery by allowing recovery from accidental database deletion and data corruption scenarios. Today, PostgreSQL Flexible server performs automatic snapshot backups and allows restoring to latest point or a custom restore point. The estimated time to recover is heavily dependent on the size of transactions logs (WAL) that need to be replayed at the time of recovery. Without having much visibility into the last full backup time, it was never easy to predict the amount of time it takes to restore.
Many enterprises have use cases like testing, development, and data verifications where they don’t always require the latest data but need the ability to spin up a server quickly to ensure business continuity, we are glad to announce that Azure Database for PostgreSQL – Flexible Server now supports theFast Restorefeature to address these use cases. This lists all the available backups that you can choose to restore. Restore with provisions a new server and restores the backup from the snapshot and as no transaction log recovery is involved, the restores are fast and predictable.
For more details about Fast Restore, refer the how-to-guide.
2. Geo Backups and Restore
Organizations around the world, such as government agencies, financial institutions, and healthcare providers, are looking for ways to protect their valuable data from regional failures including natural disasters. Azure Database for PostgreSQL Flexible Server already provides high availability (HA) using same zone and cross zone redundancy options. However, it cannot protect from all possible data loss scenarios such as a malicious actor, or logical corruption of a database.
For added disaster recovery capability, Flexible server now offers Geo Backups and Restore. This feature allows you configure your Azure postgres database to replicate snapshots and transaction logs to a paired region asynchronously through storage replication. Geo redundant backups can be restored to the server in paired region.
For more information about performing a geo-restore, refer the how-to guide.
3. Backups and Restore blade
We have heard your feedback for having better visibility into the backup and added a dedicated Backup and Restore blade in the Azure portal. This blade lists the backups available within the server’s retention period, effectively providing customers with single pane view for managing a server’s backups and consequent restores.
Customers can use this for the following:
View the completion timestamps for all available full backups within the server’s retention period
Perform restore operations using these full backups.
The list of available backups includes all full automated backups within the retention period, a timestamp showing the successful completion, a timestamp indicating how long a backup will be retained, and a restore action.
In this post, we shared some key backup and restore enhancements to provide disaster recovery within Azure database for PostgreSQL Flexible Server. Geo-backups are ideal if you need a cost-effective cross-Region DR capability that helps save on compute costs. Fast restore allows to have more predictable restore time. And backup restore blade exposing the history of full backups.
With these improvements, we continue to innovate the service offering and backup and restore capabilities of Azure Database for PostgreSQL Flexible Server.
^ RTO is Recovery Time Objective and is a measure of how quickly after an outage an application must be available again. ^^ RPO is Recovery Point Objective, refers to how much data loss an application can tolerate.
Special thanks to Kanchan Bharati for co-authoring this post.