Configure and manage automated PostgreSQL backup schedules for IBM Bob, including cron expressions, retention policies, suspend and resume, and monitoring.

Scheduled backups automate database protection and reduce the risk of data loss. IBM Bob uses Kubernetes CronJobs to execute backups according to the schedule defined in the backup configuration.

Note:

By default, backups run using Coordinated Universal Time (UTC).

Configuring backup schedules

Configure a backup schedule by updating the schedule field in the backup configuration ConfigMap. The value uses standard cron syntax and determines how often backup jobs run.

apiVersion: v1
kind: ConfigMap
metadata:
  name: bob-postgres-backup-config
  namespace: <bob-instance-namespace>
  labels:
    bob.ibm.com/backup-config: "true"
data:
  config.yaml: |
    # Backup schedule in cron format (UTC timezone)
    schedule: "0 2 * * *"  # Daily at 2:00 AM UTC

    # ... other configuration ...

Understanding cron syntax

Cron schedules consist of five fields that define the execution frequency.

Field	Values	Special characters
Minute	0–59	`*`, `,`, `-`, `/`
Hour	0–23	`*`, `,`, `-`, `/`
Day	1–31	`*`, `,`, `-`, `/`
Month	1–12	`*`, `,`, `-`, `/`
Weekday	0–7 (`0` and `7` represent Sunday)	`*`, `,`, `-`, `/`

Select a schedule that aligns with your recovery point objectives (RPOs) and business requirements.

Scheduling considerations

Timezone (UTC)

All schedules run in UTC timezone. Plan schedules according to UTC time, not your local time. For example:

0 2 * * * = 2:00 AM UTC = 4:00 AM CEST (summer) or 3:00 AM CET (winter)

Concurrent backups

All configured clusters back up simultaneously on the same schedule. This multiplies storage I/O load and shares network bandwidth across all backups. To stagger backups for resource-constrained environments, create multiple ConfigMaps with different schedules:

# ConfigMap 1: bob-db at 2 AM
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: bob-db-backup-config
  labels:
    bob.ibm.com/backup-config: "true"
data:
  config.yaml: |
    schedule: "0 2 * * *"
    clusters:
      - name: bob-db
        database: bob
        secretName: bob-db-app
---
# ConfigMap 2: keycloak-db at 3 AM
apiVersion: v1
kind: ConfigMap
metadata:
  name: keycloak-db-backup-config
  labels:
    bob.ibm.com/backup-config: "true"
data:
  config.yaml: |
    schedule: "0 3 * * *"
    clusters:
      - name: bob-keycloak-db
        database: app
        secretName: bob-keycloak-db-app

Backup duration

Consider database size when scheduling to avoid overlap between backup runs.

Database size	Expected duration
Less than 1 GB	1–5 minutes
1–5 GB	5–15 minutes
5–20 GB	15–45 minutes
20–50 GB	45–120 minutes
Greater than 50 GB	2+ hours

Off-peak hours

Schedule backups during low-usage periods. Avoid peak business hours and monitor database performance during backups.

Changing the schedule

To update the backup schedule, edit the backup ConfigMap:

oc edit configmap bob-postgres-backup-config -n <bob-instance-namespace>

Update the schedule field and save. The controller automatically detects the change and updates the CronJobs.

Verify the updated schedule:

oc get cronjob bob-db-backup-cronjob -n <bob-instance-namespace> -o jsonpath='{.spec.schedule}'

Suspending and resuming backups

If you need to pause backups during maintenance without removing the backup configuration, suspend backups in the Bob custom resource:

oc patch bob bob-instance -n <bob-instance-namespace> --type=merge \
  -p '{"spec":{"postgresBackup":{"suspend":true}}}'

Suspending backups preserves all existing backup resources while preventing new jobs from running.

Verify that CronJobs are suspended:

oc get cronjobs -n <bob-instance-namespace> -l app.kubernetes.io/component=postgres-backup
# The SUSPEND column should show "True"

Resume backups after maintenance is complete:

oc patch bob bob-instance -n <bob-instance-namespace> --type=merge \
  -p '{"spec":{"postgresBackup":{"suspend":false}}}'

Monitoring backup activity

Regular monitoring helps ensure that backup jobs continue to run successfully and that recovery objectives can be met.

# List recent backup jobs
oc get jobs -n <bob-instance-namespace> -l app.kubernetes.io/component=postgres-backup \
  --sort-by=.metadata.creationTimestamp

# Check CronJob status
oc get cronjobs -n <bob-instance-namespace> -l app.kubernetes.io/component=postgres-backup

# View last scheduled time
oc get cronjob bob-db-backup-cronjob -n <bob-instance-namespace> \
  -o jsonpath='{.status.lastScheduleTime}'

# View backup logs
oc logs -n <bob-instance-namespace> -l app.kubernetes.io/component=postgres-backup --tail=100

Investigate failures promptly to prevent gaps in backup coverage.

Managing backup retention

Retention policies determine how many backup copies are stored before older backups are automatically removed.

data:
  config.yaml: |
    # Number of backups to retain per cluster
    retention: 7  # Keep last 7 backups

Higher retention values improve recovery flexibility but require additional storage.

Retention behavior:

Oldest backups are automatically deleted after each successful backup.

Retention is per-cluster — each cluster maintains its own count.

Cleanup happens immediately after backup creation.

For example, with retention: 7:

Days 1–7: Accumulate 7 backups.

Day 8: Create a new backup, delete the day 1 backup.

Day 9: Create a new backup, delete the day 2 backup.

Triggering a manual backup

To manually trigger a backup outside the schedule:

# Create a job from the CronJob
oc create job --from=cronjob/bob-db-backup-cronjob \
  manual-backup-$(date +%s) -n <bob-instance-namespace>

# Monitor the job
oc get jobs -n <bob-instance-namespace> -l app.kubernetes.io/component=postgres-backup

# View job logs
oc logs -n <bob-instance-namespace> job/manual-backup-<timestamp>

Best practices

Schedule backups during off-peak hours (typically 2–4 AM local time).

Use a consistent schedule for predictability.

Remember UTC timezone when setting schedules.

Stagger backups if resources are constrained.

Monitor backup success regularly.

Test restore procedures monthly.

Document the schedule and rationale.

Set up alerts for backup failures.

Scheduling backups