Restore the PostgreSQL database on Red Hat OpenShift Container Platform

Restore the flightctl PostgreSQL database for Red Hat Edge Manager on Red Hat OpenShift Container Platform when you do not have an archive from flightctl-backup.

Before you begin

  • Prerequisites for the restore procedure on Red Hat OpenShift Container Platform are satisfied.
  • kubectl access to the cluster and namespace where Red Hat Edge Manager is installed.
  • flightctl and flightctl-restore installed and matching the Red Hat Edge Manager server version.
  • A tested backup of the flightctl PostgreSQL database.

About this task

Note

For recovery from a flightctl-backup archive, use the full server restore procedure. For more information about restoring the full server on Red Hat OpenShift Container Platform, see Additional resources.

Procedure

  1. Verify that the flightctl-restore version matches the Red Hat Edge Manager server version:

    From a workstation where flightctl is configured to reach the Red Hat Edge Manager API, run flightctl version (use flightctl login first if needed). The command reports Client Version (the CLI binary) and, when connected, Server Version (the running Red Hat Edge Manager instance). Run flightctl-restore version to report the restore binary version.

    flightctl version
flightctl-restore version

    Compare the output: Client Version, Server Version, and the flightctl-restore version must all report the same Red Hat Edge Manager release. If Server Version is missing or any version differs, update the mismatched binaries before you continue. For more information about prerequisites for backup and restore, see Additional resources.

    Important

    Cross-version restore is not supported. The CLI client, the running server, and flightctl-restore must be on the same release before you continue.
  2. Scale down the Red Hat Edge Manager services to avoid data conflicts during the restore process. All workloads run in a single OpenShift project. Replace the placeholder rhem-chart-namespace with your project name on every command: 
    # Replace rhem-chart-namespace with your OpenShift project (one namespace for all deployments below)
kubectl scale deployment flightctl-api --replicas=0 -n rhem-chart-namespace
kubectl scale deployment flightctl-worker --replicas=0 -n rhem-chart-namespace
kubectl scale deployment flightctl-periodic --replicas=0 -n rhem-chart-namespace
kubectl scale deployment flightctl-alert-exporter --replicas=0 -n rhem-chart-namespace
kubectl scale deployment flightctl-alertmanager-proxy --replicas=0 -n rhem-chart-namespace

    Wait for pods to stop, then verify:

    # Same namespace as above
kubectl get pods -n rhem-chart-namespace
  3. Restore the flightctl PostgreSQL database from your existing backup.

    After all Red Hat Edge Manager services are scaled down, restore the database by using the method that matches your backup strategy.

    • Target database: Restore the PostgreSQL database instance named flightctl.
    • Supported methods: Use your preferred recovery procedure, such as pg_restore, psql (for SQL dumps), or infrastructure-level volume snapshots.
    • Verification: Confirm that the database is fully accessible and that the integrity of the restored data is verified before proceeding. Important

      The specific restoration commands depend on your backup strategy and tools. Ensure the database is fully restored and consistent before you continue.
  4. Retrieve database and KV store credentials (same namespace as the scale commands): 
    DB_APP_PASSWORD=$(kubectl get secret flightctl-db-app-secret -n rhem-chart-namespace -o jsonpath='{.data.userPassword}' | base64 -d)

echo "Database password retrieved successfully"
     
    KV_PASSWORD=$(kubectl get secret flightctl-kv-secret -n rhem-chart-namespace -o jsonpath='{.data.password}' | base64 -d)
  5. Configure port forwarding for the database and the KV store. Use separate terminal sessions for each port forward, or run them in the background.

    Forward the database service:

    # Forward database port (run in a separate terminal or in the background)
kubectl port-forward svc/flightctl-db 5432:5432 -n rhem-chart-namespace &
DB_PORT_FORWARD_PID=$!

# Verify database connectivity (if available)
pg_isready -h localhost -p 5432

    Forward the KV store service:

    # Forward KV store port (run in a separate terminal or in the background)
kubectl port-forward svc/flightctl-kv 6379:6379 -n rhem-chart-namespace &
KV_PORT_FORWARD_PID=$!

# Verify KV store connectivity (if available)
REDISCLI_AUTH="$KV_PASSWORD" redis-cli -h localhost -p 6379 ping
  6. Run the restore command by using environment variables for the database and KV store passwords: 
    DB_PASSWORD="$DB_APP_PASSWORD" KV_PASSWORD="$KV_PASSWORD" flightctl-restore

    Monitor the command output until it completes successfully. If it fails or logs per-device KV errors, keep workloads scaled to zero. For more information about recovering from a failed or partial restore, see Additional resources before you stop port-forwards or scale services back up.

  7. Stop the port-forward processes when the restore finishes: 
    kill $DB_PORT_FORWARD_PID $KV_PORT_FORWARD_PID

    If you ran the port forwards in separate terminals instead, stop them with Ctrl+C in those terminals.

  8. Restart Red Hat Edge Manager services. Scale the deployments back to their normal replica counts in the same OpenShift project as in step 2: 
    # Replace rhem-chart-namespace with your OpenShift project (same single namespace for every command)
kubectl scale deployment flightctl-api --replicas=1 -n rhem-chart-namespace
kubectl scale deployment flightctl-worker --replicas=1 -n rhem-chart-namespace
kubectl scale deployment flightctl-periodic --replicas=1 -n rhem-chart-namespace
kubectl scale deployment flightctl-alert-exporter --replicas=1 -n rhem-chart-namespace
kubectl scale deployment flightctl-alertmanager-proxy --replicas=1 -n rhem-chart-namespace
kubectl get deployments -n rhem-chart-namespace
kubectl get pods -n rhem-chart-namespace

Results

  • Pods are running and the API responds.
  • Devices reconnect without full re-enrollment when PKI and endpoints are unchanged.
  • Device inventory matches expectations in the web console or with flightctl CLI commands.