Minimize Interruptions and Travel Back in Time with VMware SQL with Postgres for Kubernetes

The recent minor release of VMware SQL with Postgres for Kubernetes packs a major punch. Version 1.8 boasts more than half a dozen new capabilities, many of which enhance the availability and recoverability of managed Postgres database instances running on K8s clusters. Three of the more prominent features are detailed below. 

Point-in-Time Recovery

Accidents happen. Someone inadvertently updates, modifies, or deletes production data. Incidents happen. System failure, file system damage, or database corruption. Regardless of whether an accident or incident occurs, you will be left scrambling to restore service to your database.

Not to worry. Point in Time Recovery allows you to travel back in time, to a user-determined point prior to the occurrence of the adverse event. Below is a diagram of Point in Time Recovery followed by a description of how it works:

1. A database table is mistakenly overwritten at 10:25
2. To recover the table, the decision is to restore the database to 10:20
3. Using the most recent backup prior to the adverse event (06:00), the database is restored
4. Postgres replays all the Write-Ahead Log (WAL) files to bring the database to the user-specified time of 10:20

Continuous Restore

The previous minor release of VMware SQL Postgres (Version 1.7) incorporated some major enhancements to backup and recovery while providing the building blocks for disaster recovery. The mechanism used for disaster recovery is Continuous Restore.

Continuous Restore automates data synchronization and other configurations to accelerate the failover of Postgres instances between multiple Kubernetes clusters regardless of where the clusters are running (on-prem or in the cloud). In the event of a Kubernetes cluster failure, Continuous Restore helps expedite recovery and minimize interruptions. The following diagram outlines this new feature.

Continuous Restore is described as follows:

1. A backup is executed on the Source instance (automated or on-demand)
2. The backup is automatically archived in the remote storage location
3. From the remote storage location, the backup is automatically synced onto the target cluster and namespace
4. Once the sync is complete, the backup is automatically restored to the Target instance
5. Should an outage occur on the Source instance, the Target instance can be promoted to the primary instance (see diagram below).

Azure Blob Storage

VMware SQL Postgres allows considerable flexibility for backup and recovery. Backups can be scheduled to run automatically or executed on-demand. In addition, restores can be performed in-place or against an entirely new Postgres instance. 

Prior to version 1.8, the supported locations for uploading and retrieving backup artifacts were Amazon S3 or another S3-compatible data store. The current version now supports archiving backups to Microsoft Azure Blob Storage.

The recent minor release of Vmware SQL with Postgres is full of major new product features. Check out this video for more details and a demonstration of the highlighted new features above.