Crunchy Data Postgres Operator Logical Backup and Restore
Crunchy Data Postgres Operator (PGO) uses the open-source pgBackRest tool to backup and restore PostgreSQL data. The K10 platform integrates with PGO to perform backup and restore PostgreSQL data using the operator APIs.
You can find the steps for installing PGO and PostgresCluster here.
Before you begin, make sure you understand the known limitations of the current integration.
By default, K10 utilizes built-in Kanister Blueprints for managing data
services like PGO and K8ssandra. If you wish to disable this feature, you
can use the
kanister.managedDataServicesBlueprintsEnabled=false Helm flag
during the installation of K10.
K10 uses PGO APIs to perform Backup and Restore of PostgreSQL data.
Since PGO uses the
pgBackRest tool for managing backups,
please take a note of the following limitations:
As of now, K10 supports only in-place restoration. That means the PostgresCluster backed up needs to be present to run restore.
Restoring to a different namespace or migration is not supported as of now. This can be done manually by cloning the PostgresCluster by following the official documentation.
PGO must be running before performing PostgresCluster restore.
PGO performs PITR to restore data. PostgreSQL PITR runs recovery till the next commit it finds after the specified timestamp. Hence while restoring the latest restore point, please make sure that there exists a commit after the timestamp. If there is no database commit after the restore timestamp, the restore job may get stuck with the error
recovery ended before configured recovery target was reached. To recover from this situation, try to restore to an older restore point.
PGO does not support an API for deleting the
pgBackRestrestore point. Due to this reason, K10 cannot delete PostgresCluster restore point as per the K10 Policy's retention configuration. It is recommended to set the correct retention configuration in the
PostgresClusterspec. The details about managing PGO backup retention can be found here. Also, note that the PGO repository can be different from the K10 Location Profiles.
PGO Backup with K10
Enable Manual Backups on PostgresCluster
To allow K10 to perform on-demand backup, manual backups need to be enabled on the PostgresCluster. This can be done by applying the following patch to the PostgresCluster CR
kubectl patch postgrescluster NAME --namespace NAMESPACE --type merge --patch "$(cat << EOM spec: backups: pgbackrest: manual: repoName: <REPO-NAME> options: - --type=incr EOM )"
REPO-NAME is the backup repository configured for PGO.
The complete list of supported backup repositories can be found
Once PostgresCluster CR is patched to enable manual backups, a K10 Policy can be created to perform backups of the PGO application.
PGO Restore with K10
PostgresCluster components are managed by the PGO. The StatefulSet workloads are created by the operator when a PostgresCluster Custom Resource is created. For this reason, the StatefulSet objects do not need to be restored as they are managed by the operator.
Follow the steps below to restore PostgresCluster without conflicting with the functioning of the operator.
Select the Restore Point that needs to be restored.
Deselect all the artifactsunder the
SpecArtifacts, select only artifact(s) of type
Click Restore to perform the restore of PostgresCluster and data.