RDS PostgreSQL Backup

There are two ways with which backup can be performed on AWS RDS PostgreSQL instance data with Kanister:

  1. Create an RDS instance snapshot.

  2. Create an RDS snapshot, extract PostgreSQL data, push that data to object storage, and delete the RDS snapshot

Create Secret and ConfigMap

To facilitate K10 to connect to the RDS instance, K10 needs RDS instance details and the username, password to login to the database created in RDS. This information is provided by creating ConfigMap and Secret Kubernetes resources.

Create a Kubernetes secret to store PostgreSQL credentials into rds-app namespace. If there are other RDS instances, multiple ConfigMap/Secret pairs can be created to have the details of those RDS instances.

apiVersion: v1
kind: Secret
metadata:
  name: dbcreds
  namespace: rds-app
type: Opaque
# Note: the keys below must be base64 encoded:
# printf "YOUR_KEY" | base64
data:
  username: <base64-encoded-username>
  password: <base64-encoded-password>

Create a ConfigMap in rds-app namespace which contains information to connect to the RDS DB instance

apiVersion: v1
kind: ConfigMap
metadata:
  name: dbconfig
  namespace: rds-app
data:
  postgres.instanceid: test-rds-postgresql      # instanceid of of the database created in RDS
  postgres.host: test-rds-postgresql.example.ap-south-1.rds.amazonaws.com
  postgres.databases: |       # databases to take backup of
    - postgres
    - template1
  postgres.secret: dbcreds    # name of K8s secret in the same namespace

Create Blueprint

There are two ways with which backup and restore can be performed on an RDS instance:

  1. Create an RDS instance snapshot - Using rds-postgres-snap-blueprint.yaml Blueprint.

    Advantages:

    • This approach transparently leverages AWS's storage volume snapshot functionality.

    • The backup operation is relatively faster than the second approach.

    • Restore is comparatively faster if the data size is too large.

    Limitations:

    • Snapshot data cannot be exported into object storage.

    • A Non-RDS PostgreSQL instance cannot be restored with the data.

  2. Create an RDS snapshot, extract PostgreSQL data, push that data to object storage, and finally delete the RDS snapshot - Using rds-postgres-dump-blueprint.yaml Blueprint.

    Advantages:

    • Restore is faster if the data size is small.

    • Backed up data can be exported and saved on object storage.

    • Data can be restored on the non-RDS PostgreSQL instance as well.

    Limitations:

    • Restore operation could be time-consuming if data size if too large.

    • Backup is slower than the first approach as compared to the first approach since the backup is performed in 3 steps:

      1. Create an RDS Snapshot

      2. Create the DB data dump and push it to object storage

      3. Delete the RDS Snapshot

Create a Blueprint as per the chosen approach.

Use the rds-postgres-snap-blueprint.yaml Blueprint if backup needs to be performed using RDS snapshots or use the rds-postgres-dump-blueprint.yaml Blueprint if backup needs to be performed by extracting PostgreSQL dump from the RDS snapshot and push to S3 storage

Warning

With both approaches, RDS snapshots are created to perform backups. These operations are prone to fail if Manual snapshots quota is reached (which is 100 by default). Make sure that correct retention policies are set to avoid getting into this issue.

$ kubectl create -f <blueprint> -n kasten-io

Once the Blueprint is created, the ConfigMap containing connection info will need to be annotated to instruct K10 to use the Blueprint while performing backup operations on this RDS PostgreSQL DB instance. The following example demonstrates how to annotate the dbconfig ConfigMap with the RDS Blueprint.

$ kubectl annotate configmap dbconfig kanister.kasten.io/blueprint=<blueprint-name> --namespace=rds-app

Finally, use K10 to backup and restore the RDS instance.