此内容没有您所选择的语言版本。
Chapter 1. Backing up the PostgreSQL database for Red Hat Edge Manager on Red Hat Enterprise Linux
Red Hat Edge Manager stores control-plane data in PostgreSQL when you install the flightctl-services RPM on Red Hat Enterprise Linux. This topic covers database backup scope, recovery point objectives (RPOs), and practices that complement database backups for an RPM deployment.
1.1. Overview 复制链接链接已复制到粘贴板!
PostgreSQL is the primary data store for the Red Hat Edge Manager control plane. It holds device and fleet configuration, organizations, templates, user-related metadata, and other system state required to operate Flight Control.
You must define a Recovery Point Objective (RPO) that matches your business requirements, compliance obligations, and risk tolerance. Typical baselines include the following:
- Mission-critical environments: RPO on the order of 15 minutes
- Non-production or development environments: RPO up to 24 hours
You are responsible for implementing and operating your own backup and restore procedures for the PostgreSQL database. Red Hat Edge Manager documents strategy and recommendations; it does not perform or manage backups for your deployment.
1.2. Database backup scope 复制链接链接已复制到粘贴板!
To recover the control plane after data loss or corruption, back up the PostgreSQL database that contains the flightctl schema (including all application data tables), together with the following:
- Data: Devices, fleets, organizations, templates, and related records
- Schema: Table definitions and migrations that match your installed Red Hat Edge Manager release
- Security metadata: Database roles, grants, and users required for the application to access the database
The database runs as part of the Flight Control services you manage with systemctl on the Red Hat Enterprise Linux host (for example, under flightctl.target). Use the backup tooling your organization standardizes on (for example, logical dumps or filesystem snapshots) as long as you can restore a consistent copy of the flightctl database that matches your operational runbooks.
1.3. Testing backups 复制链接链接已复制到粘贴板!
Validate backups regularly. Untested backups are a common source of failed recoveries.
- Create an isolated test environment that mirrors production closely enough to exercise a restore (same major Red Hat Edge Manager version and similar configuration).
- Restore from your most recent backup using your chosen restore procedure.
- Verify data integrity by listing Flight Control resources (for example, devices and fleets) and comparing them to a known-good source.
- Confirm that the Red Hat Edge Manager API and web console behave as expected against the restored database.
- Record any gaps, errors, and corrective actions in your runbooks.
1.4. Recommended practices 复制链接链接已复制到粘贴板!
-
Git-backed configuration: Store declarative configuration in Git and sync it with the control plane using
Repositoryresources andgitRefin device and fleet specifications where appropriate. For a CLI-oriented workflow, see Managing the device configuration from a Git repository on the CLI. - Separate failure domain for Git: Host Git repositories outside the same failure domain as the Red Hat Edge Manager host when possible (for example, a managed Git service or a separate cluster).
-
Back up deployment configuration: Include
/etc/flightctl/service-config.yamland any drop-in configuration your deployment uses (for example, under/etc/flightctl/conf.d/) in your configuration-management backups so you can rebuild or reinstall the host consistently. - Version and tag changes: Track changes to configuration and automation with version control and tags so you can roll back or redeploy predictably.
- Restoring on Red Hat Enterprise Linux: When you need to recover the database on the host, follow Restoring the PostgreSQL database for Red Hat Edge Manager on Red Hat Enterprise Linux.