Review the boundaries and constraints that apply when you plan backup and restore for Red Hat Edge Manager.

• Same-version restore only: You can restore an archive only to a Red Hat Edge Manager instance running the same version recorded in the archive metadata. Do not attempt to restore a backup taken on one release onto a host or cluster upgraded to a newer release.
• Full backups only:flightctl-backup creates a full snapshot. Incremental or differential backups are not supported in this release.
• No cross-deployment restore: An archive created on a Podman quadlet deployment cannot be restored on a Kubernetes or Helm deployment, and the reverse is not supported. The restore command detects deployment type from the archive and fails with a clear error on mismatch.
• No built-in remote storage: The commands write a local archive (and checksum file). Copying archives to object storage, NFS, or tape is your responsibility. Red Hat Edge Manager does not ship S3, NFS, or similar backup targets.
• No backup encryption: Archives are not encrypted by the product. Use storage-level encryption, filesystem encryption, or your organization’s secret-management practices to protect backup media.
• No native scheduler: Red Hat Edge Manager does not run scheduled backups internally. Use cron, Ansible, Kubernetes CronJobs, or your automation platform. For more information about scheduling backups, see Additional resources.
• External PostgreSQL: When the database runs outside the deployment, flightctl-backup does not dump that database; it prints guidance and still backs up PKI and configuration. Your database team must back up and restore external instances. For more information about external PostgreSQL databases, see Additional resources.
• Device state after restore: Devices enrolled after the backup was taken, or devices with specification drift, can require re-approval or operator action. For more information about post-restore device status changes, see Additional resources.
• Restore is not transactional:flightctl-restore can leave the deployment in a partial state if it fails mid-run (for example, the KV store cleared before all device records are updated). Device preparation also logs per-device KV key failures without always failing the command. For more information about recovering from a failed or partial restore, see Additional resources.