Restore the full server on Red Hat Enterprise Linux

Run flightctl-restore with a flightctl-backup archive to recover Red Hat Edge Manager on a Red Hat Enterprise Linux host of the same version. The command verifies the checksum, restores the database, PKI, and configuration, and prepares devices to reconnect without re-enrollment.

Before you begin

  • A valid backup archive and matching .sha256 file from flightctl-backup on the same Red Hat Edge Manager version as the target host.
  • Prerequisites for backup and restore are satisfied.
  • Application services must be stopped during restore. PostgreSQL and the KV store must remain running.

Procedure

  1. Verify that flightctl and flightctl-restore match the running Red Hat Edge Manager server:

    Run flightctl version from a host where the CLI can reach the Red Hat Edge Manager API (use flightctl login 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. Verify archive integrity before any service changes. Run the command from the directory that contains the archive and .sha256 file, or pass the full path to the checksum file. The output must include OK: 
    sha256sum -c /path/to/flightctl-backup-YYYYMMDDTHHMMSSZ.tar.gz.sha256

    If verification fails, do not continue. For more information about the checksum file, see Additional resources.

  3. Stop Red Hat Edge Manager application services only. Do not stop flightctl-db.service or flightctl-kv.service: 
    sudo systemctl stop flightctl-gateway.service
sudo systemctl stop flightctl-api.service
sudo systemctl stop flightctl-worker.service
sudo systemctl stop flightctl-periodic.service
sudo systemctl stop flightctl-alert-exporter.service
sudo systemctl stop flightctl-alertmanager-proxy.service
sudo systemctl stop flightctl-telemetry-gateway.service
sudo systemctl stop flightctl-pam-issuer.service
sudo systemctl stop flightctl-cli-artifacts.service
sudo systemctl stop flightctl-alertmanager.service
sudo systemctl stop flightctl-imagebuilder-api.service
sudo systemctl stop flightctl-imagebuilder-worker.service
sudo systemctl stop flightctl-ui.service
    Note

    Skip units that do not exist on your host. Do not run systemctl stop flightctl.target.
  4. If the archive-based restore requires database and KV passwords, retrieve credentials from Podman secrets as in the manual restore procedure. Publish ports if your environment requires it, then run restore with the archive path: 
    DB_APP_PASSWORD=$(sudo podman secret inspect flightctl-postgresql-user-password --showsecret | jq -r '.[0].SecretData')
KV_PASSWORD=$(sudo podman secret inspect flightctl-kv-password --showsecret | jq -r '.[0].SecretData')
export DB_PASSWORD="$DB_APP_PASSWORD" KV_PASSWORD="$KV_PASSWORD"
flightctl-restore /path/to/flightctl-backup-YYYYMMDDTHHMMSSZ.tar.gz

    Monitor the command output until it completes successfully. flightctl-restore is not transactional: a mid-run failure can leave the deployment partially restored. Do not start application services until restore finishes without error.

    Important

    If the command fails or logs per-device KV errors, keep application services stopped. For more information about recovering from a failed or partial restore, see Additional resources before you continue.

     Note

    When your release restores without separate port publishing, follow the command output from flightctl-restore --help for your version. The archive path is the first positional argument.
  5. Start application services again (same units you stopped): 
    sudo systemctl start flightctl-api.service
sudo systemctl start flightctl-worker.service
sudo systemctl start flightctl-periodic.service
sudo systemctl start flightctl-alert-exporter.service
sudo systemctl start flightctl-alertmanager-proxy.service
sudo systemctl start flightctl-telemetry-gateway.service
sudo systemctl start flightctl-pam-issuer.service
sudo systemctl start flightctl-cli-artifacts.service
sudo systemctl start flightctl-alertmanager.service
sudo systemctl start flightctl-imagebuilder-api.service
sudo systemctl start flightctl-imagebuilder-worker.service
sudo systemctl start flightctl-ui.service
sudo systemctl start flightctl-gateway.service
  6. Confirm API health and review device status in the console or CLI.

Results

  • flightctl API calls succeed.
  • Devices move from AwaitingReconnect to online where expected.
  • No checksum or deployment-type errors appeared during restore.