Setting Up Database Backups

Resonate RFID Reader Management 2.0 User Guide

Currently, database backups are handled in multi-node deployments through the presence of database replicas running simultaneously on each node. This ensures that if one node fails, the data is still available on another node. In the event that you need database backups for a single-node deployment, or if you want to have additional backups for your multi-node deployment, you can set up periodic database dumps using the postgres system that

Resonate RFID Reader Management

uses.

CNPG Backups using Barman

Resonate RFID Reader Management

uses Cloudnative Postgres (CNPG), which has its own documentation on setting up database backups.

CNPG allows you to configure your cluster to automatically upload backups to one of various cloud storage providers, including AWS S3, Google Cloud Storage, and Azure Blob Storage. This can be set up to run at regular intervals, ensuring that you always have a recent backup available.

Configure this according to CNPG’s documentation, by adding backup rules to the following files:

manifests/base/postgres.yml

(For application data, configuration of readers, etc.)

manifests/base/keycloak.yml

(For user and authentication data)

Add a backup section under the

spec

of the kind: Cluster objects in both files.

Also, create a secret with the relevant credentials for your chosen cloud provider, and reference this secret in the

barmanObjectStore

section of the backup configuration.

Set up a schedule for the backups by creating a

ScheduledBackup

object in those files, similar to the following:

--- # For backing up the application database
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: trifecta-backup
  namespace: zebra-reader-management
spec:
  cluster: trifecta-postgres
  schedule: "0 0 2 * * *" # Daily at 2 AM

--- # For backing up the Keycloak database
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: keycloak-backup
  namespace: zebra-reader-management
spec:
  cluster: keycloak-db
  schedule: "0 0 3 * * *" # Daily at 3 AM

After you have configured it according to your needs, apply the changes by running the install script again, or by applying the manifests directly using:

kubectl apply -k deploy

Single-Node Database Backups

For single-node deployments, use the

pg_dumpall

command to create a backup of your database. Schedule this command using

corn

jobs or similar scheduling tools to ensure regular backups:

kubectl exec -i trifecta-postgres-1 -n zebra-reader-management -- pg_dumpall | gzip > /path/to/backup/trifecta-$(date +%Y%m%d%H%M%S).sql.gz 

kubectl exec -i keycloak-db-1 -n zebra-reader-management -- pg_dumpall | gzip > /path/to/backup/keycloak-$(date +%Y%m%d%H%M%S).sql.gz

Multi-Node Database Backups

The single-node backup procedure also works for a multi-node deployment, although you might need to identify the correct pod names for the PostgreSQL instances. You can find the pod names using:

kubectl get pods -n zebra-reader-management

This lists all pods in the zebra-reader-management namespace, allowing you to identify the PostgreSQL pods for both the application and Keycloak databases. They should have names such as

trifecta-postgres-<N>

and

keycloak-db-<N>

After you have identified the correct pod names, run the

pg_dumpall

commands as follows to create backups of both databases:

kubectl exec -i trifecta-postgres-1 -n zebra-reader-management -- pg_dumpall | gzip > /path/to/backup/trifecta-$(date +%Y%m%d%H%M%S).sql.gz
 
kubectl exec -i keycloak-db-1 -n zebra-reader-management -- pg_dumpall | gzip > /path/to/backup/keycloak-$(date +%Y%m%d%H%M%S).sql.gz

Recovering from Database Backups

For recovery, restore the database from the backup using the

psql

command:

zcat /path/to/backup/trifecta-YYYYMMDDHHMMSS.sql.gz | kubectl exec -i trifecta-postgres-1 -n zebra-reader-management -- psql
 
zcat /path/to/backup/keycloak-YYYYMMDDHHMMSS.sql.gz | kubectl exec -i keycloak-db-1 -n zebra-reader-management -- psql