Prerequisites for backup and restore

Confirm that your environment meets the software, access, and operational requirements before you run flightctl-backup or flightctl-restore.

Software versions
Copy link

  • Red Hat Edge Manager release (restore): Before restore, install Red Hat Edge Manager on the replacement host or cluster at the same release recorded in the backup archive. The backup archive must be from the same Red Hat Edge Manager release as the newly installed instance.
  • Matching CLI tools:flightctl, flightctl-backup, and flightctl-restore on the machine where you run the commands must match the Red Hat Edge Manager server release. Version checks work as follows:
    • flightctl version always reports Client Version (the flightctl CLI binary). When the CLI is configured and can reach the Red Hat Edge Manager API, the same command also reports Server Version (the running Red Hat Edge Manager instance). Use flightctl login if Server Version is missing.
    • flightctl-backup version and flightctl-restore version report the version of those binaries.

      Run the commands from a host that can reach the Red Hat Edge Manager API:

      flightctl version
flightctl-backup version
flightctl-restore version

      Client Version, Server Version (when shown), and the backup and restore tool versions must all match. If any version differs, do not run backup or restore until you install or replace the mismatched binaries from the same Red Hat Edge Manager release as the server. On Red Hat Enterprise Linux, install or upgrade packages from the same repository channel as flightctl-services (for example, sudo dnf upgrade -y flightctl-cli). On Red Hat OpenShift Container Platform, install matching CLIs on the workstation from the product repository or the Red Hat Edge Manager UI download. Re-run the version commands above to confirm alignment before you continue. For more information about the version compatibility matrix and installing the Flight Control CLI, see Additional resources.

      Important

      Cross-version restore is not supported. For more information about backup and restore limitations, see Additional resources.

Tools by deployment type
Copy link

Tool Red Hat Enterprise Linux (Podman quadlet) Red Hat OpenShift Container Platform (Kubernetes or Helm)

flightctl-backup, flightctl-restore

Required on the host or a management host with access to deployment paths and credentials

Required inside the cluster (run as Kubernetes Job or CronJob with ServiceAccount and RBAC permissions)

pg_dump, psql

Required in PATH when the deployment uses the internal PostgreSQL database

Must be available inside the database pod (pre-installed in flightctl-db image); not required on the host running the backup Job

kubectl

Not required; flightctl-backup and flightctl-restore use the host filesystem and Podman on Red Hat Enterprise Linux

Not required by flightctl-backup (uses Kubernetes Go API); needed only for deploying and managing the backup Job or CronJob

helm

Not required

Not required by flightctl-backup (reads Helm release Secrets via Kubernetes API); CLI not used

sha256sum or equivalent

Required to verify archive integrity

Required to verify archive integrity (available in backup Job container)

Access and privileges
Copy link

  • Red Hat Enterprise Linux: Root or sudo access to stop and start Flight Control systemd units, read PKI under /etc/flightctl/pki/, and run Podman commands when volumes are exported.
  • Red Hat OpenShift Container Platform: ServiceAccount with RBAC permissions to list Pods, read Secrets, and exec into Pods in the Red Hat Edge Manager namespace. Cluster-admin or namespace admin is required to create the backup Job or CronJob initially.
  • Archive storage: Writable directory for backup output (--output) with space for the full archive; restrict permissions on backup files (archives are created with owner-only access).

Operational readiness
Copy link

  • A maintenance window or change record for restore operations that stop application services or scale workloads to zero.
  • A tested path to copy archives off the host or cluster (backup files are local; transport to remote storage is your responsibility).
  • For restore validation, a plan to confirm API health, inventory, and device reconnection. For more information about post-restore device status changes, see Additional resources.