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.

Note

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.

Known Limitations

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 pgBackRest restore 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 PostgresCluster spec. 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
)"

Where, REPO-NAME is the backup repository configured for PGO. The complete list of supported backup repositories can be found here.

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

Restore PostgresCluster

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.

  1. Select the Restore Point that needs to be restored.

  2. Deselect all the artifacts under the Artifacts section.

  3. Now, under Spec Artifacts, select only artifact(s) of type postgresclusters.

  4. Click Restore to perform the restore of PostgresCluster and data.