Restore the database without flightctl-restore

If your operations team restores the PostgreSQL data without running flightctl-restore, stop only application services so the database and KV store keep running. Do not run systemctl stop flightctl.target, which stops all services including the database and KV store.

Before you begin

  • Prerequisites for the restore procedure are satisfied.
  • Root or sudo access to the host where the quadlets run.
  • A tested backup of the flightctl PostgreSQL database.

Procedure

  1. Stop the application services only (same list as in the Restore by using quadlets and flightctl-restore procedure, step 2). Skip units that do not exist on your host.
  2. Restore the flightctl database by using the procedure that matches your backup while PostgreSQL remains available:
    • Logical backups (dump files): Use pg_restore, psql, or equivalent clients per your DBA standards.
    • Storage or snapshot restores: Restore the data directory or volume following your infrastructure playbook.

      Ensure database name, roles, and grants match what Red Hat Edge Manager expects.

  3. Verify that PostgreSQL accepts connections and that the flightctl database is present (for example, pg_isready or a short test query).
  4. Start the application services again with the same systemctl start sequence as in the Restore by using quadlets and flightctl-restore procedure, step 11. Do not rely on systemctl start flightctl.target unless your runbook confirms it does not disrupt the database or KV units you left running.
  5. Confirm health (for example, sudo systemctl status flightctl-api.service) and validate data in the web console or with flightctl CLI commands.

Results

  • Application services are active and running.
  • The Red Hat Edge Manager API responds to flightctl CLI commands.
  • Device inventory matches expectations in the web console.