Restore IBM Bob PostgreSQL databases from a backup to recover from data loss, migrate environments, or return to a known-good state.

Use this procedure to restore IBM Bob and related PostgreSQL databases from backup files. The restoration process includes validating backup integrity, preparing the environment, recreating the target database, restoring the backup contents, and verifying the restored data before returning application services to service.

Warning:

Restoring a database replaces the existing database contents with data from the selected backup file. Application services must be stopped before beginning, as active database writes can corrupt the restoration process. Always test restoration procedures in a non-production environment before performing a production recovery.

Before you begin

Before restoring a database, verify the following:

Verify backup integrity

# Access backup PVC
oc run backup-verify -n <bob-instance-namespace> --image=busybox --rm -it --restart=Never \
  --overrides='{
    "spec": {
      "containers": [{
        "name": "backup-verify",
        "image": "busybox",
        "command": ["sh"],
        "stdin": true,
        "tty": true,
        "volumeMounts": [{
          "name": "backup",
          "mountPath": "/backups"
        }]
      }],
      "volumes": [{
        "name": "backup",
        "persistentVolumeClaim": {
          "claimName": "bob-db-backup-pvc"
        }
      }]
    }
  }'

# Inside the pod:
cd /backups/bob-db
gunzip -t backup_bob_20260902_020000.sql.gz  # Test gzip integrity
cat backup_bob_20260902_020000.sql.gz.meta   # Check metadata

Confirm backup details

Backup timestamp matches the expected restore point.

Database name is correct.

Backup size is reasonable.

Metadata file exists and is readable.

Create a pre-restore backup

Before restoring, back up the current database state:

oc exec -n <bob-instance-namespace> bob-db-1 -- \
  pg_dump -U postgres bob | gzip > pre-restore-backup-$(date +%Y%m%d_%H%M%S).sql.gz

Restore procedure

Stop all IBM Bob application services to prevent database writes during restoration.

# Scale down Bob services
oc scale deployment bob-admin-service --replicas=0 -n <bob-instance-namespace>
oc scale deployment bob-api-service --replicas=0 -n <bob-instance-namespace>
oc scale deployment bob-ui-service --replicas=0 -n <bob-instance-namespace>

# Verify pods are terminated
oc get pods -n <bob-instance-namespace> -l app.kubernetes.io/name=bob

Create a temporary restoration pod that has access to both the PostgreSQL database and the backup storage location.

# Get PostgreSQL image
POSTGRES_IMAGE=$(oc get cluster bob-db -n <bob-instance-namespace> -o jsonpath='{.spec.imageName}')

# Create restore pod
oc run postgres-restore -n <bob-instance-namespace> --image=$POSTGRES_IMAGE --rm -it --restart=Never \
  --overrides='{
    "spec": {
      "containers": [{
        "name": "restore",
        "image": "'$POSTGRES_IMAGE'",
        "command": ["bash"],
        "stdin": true,
        "tty": true,
        "env": [
          {"name": "PGHOST", "value": "bob-db-rw"},
          {"name": "PGPORT", "value": "5432"},
          {"name": "PGUSER", "value": "postgres"},
          {"name": "PGPASSWORD", "valueFrom": {"secretKeyRef": {"name": "bob-db-app", "key": "password"}}}
        ],
        "volumeMounts": [{
          "name": "backup",
          "mountPath": "/backups"
        }]
      }],
      "volumes": [{
        "name": "backup",
        "persistentVolumeClaim": {
          "claimName": "bob-db-backup-pvc"
        }
      }]
    }
  }'

Inside the restore pod, verify the backup file and test the database connection:

# List available backups
ls -lh /backups/bob-db/

# Verify backup file
BACKUP_FILE="/backups/bob-db/backup_bob_20260902_020000.sql.gz"
gunzip -t $BACKUP_FILE
echo "Backup file is valid"

# Check metadata
cat ${BACKUP_FILE}.meta

# Test database connection
psql -c "SELECT version();"

For most recovery scenarios, restore into an empty database to ensure that obsolete or conflicting data is removed.

Warning:

This step permanently removes the current database contents.

psql -c "DROP DATABASE IF EXISTS bob;"
psql -c "CREATE DATABASE bob;"

Restore the database by loading the backup contents into PostgreSQL:

# Extract and restore backup
gunzip -c $BACKUP_FILE | psql -d bob

# This may take several minutes depending on backup size

Before returning the application to service, verify that the restoration completed successfully:

# Connect to restored database
psql -d bob

# Verify tables exist
\dt

# Check row counts for key tables
SELECT COUNT(*) FROM users;
SELECT COUNT(*) FROM projects;
SELECT COUNT(*) FROM conversations;

# Verify recent data
SELECT * FROM users ORDER BY created_at DESC LIMIT 10;

# Exit psql
\q

After database validation completes successfully, restart IBM Bob services and allow them to reconnect to the restored database. Monitor application startup logs for errors or migration failures.

# Exit restore pod
exit

# Scale up Bob services
oc scale deployment bob-admin-service --replicas=1 -n <bob-instance-namespace>
oc scale deployment bob-api-service --replicas=3 -n <bob-instance-namespace>
oc scale deployment bob-ui-service --replicas=2 -n <bob-instance-namespace>

# Verify pods are running
oc get pods -n <bob-instance-namespace> -l app.kubernetes.io/name=bob

# Check application logs
oc logs -n <bob-instance-namespace> -l app.kubernetes.io/name=bob --tail=50

Complete an end-to-end application validation before allowing users to reconnect:

# Test application endpoints
curl -k https://bob.example.com/health

# Verify user login works
# Verify data access works
# Verify key functionality works

Successful validation indicates that the restoration process is complete.

Best practices

Always test in a non-production environment first.

Create a pre-restore backup of the current database state before beginning.

Verify backup integrity before starting.

Plan for downtime and communicate with users.

Document the restoration process and results.

Verify data integrity after restoration.

Monitor the application closely after restoration.

Common restoration issues

Issue	Cause	Solution
Insufficient space	Not enough disk space for the restore operation	Expand the PVC or free up storage space before restoring.
Connection timeout	Network connectivity issues or database availability problems	Verify database connectivity and increase timeout values if necessary.
Permission errors	Restore user does not have the required database privileges	Grant the necessary permissions to the restore user before running the restore operation.

Restoring a backup

Before you begin

Restore procedure

Best practices

Common restoration issues

On this page