Application Consistent PostgreSQL HA Backup and Restore

If it hasn't been done already, the bitnami Helm repository needs to be added to your local configuration:

# Add bitnami helm repo
$ helm repo add bitnami https://charts.bitnami.com/bitnami

Install the PostgreSQL HA chart from the bitnami Helm repository:

$ kubectl create namespace postgresql
$ helm install postgresql bitnami/postgresql-ha --namespace postgresql

Use K10 to backup and restore the application.

Using Post Restore Hook Blueprint

Note

The provided example in this section serves as a blueprint template for achieving application-consistent PostgreSQL HA backup and restore workflows. Please note that these examples may need to be modified for specific production environments and setups. As a result, it is highly recommended to carefully review and modify the blueprints as needed before deploying them for production use.

If the PostgreSQL HA application is being restored into a different namespace, the secondary instance pod postgresql-postgresql-ha-postgresql-1 will go into CrashLoopBackOff since the connection info for the primary/secondary nodes in the repmgr database points to the source namespace. The following additional steps are needed to solve this issue:

Create a snapshot for the PostgreSQL HA application using K10
Create a blueprint in the kasten-io namespace. This blueprint will operate as a post restore hook

$ kubectl --namespace kasten-io apply -f \
  https://raw.githubusercontent.com/kanisterio/kanister/0.107.0/examples/postgresql-ha/hook-blueprint/postgres-ha-hook.yaml

During restore, create a different namespace - postgresql-2 and select it as the target namespace
Under the Pre and Post-Restore Action Hooks section, select the check box After - On Success and select the blueprint created in step 2 as the action hook with action as postRestoreHook. Select the checkbox Don't wait for workloads to be ready