Backup and restore

Red Hat Edge Manager 1.1

Instructions on backing up and restoring Red Hat Edge Manager

Red Hat Edge Manager Documentation Team

Abstract

This document provides information on backing up and restoring Red Hat Edge Manager.

Preface

Back up and restore the Red Hat Edge Manager PostgreSQL database and control plane on Red Hat Enterprise Linux or Red Hat OpenShift Container Platform.

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
Important

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.

  1. Create an isolated test environment that mirrors production closely enough to exercise a restore (same major Red Hat Edge Manager version and similar configuration).
  2. Restore from your most recent backup using your chosen restore procedure.
  3. Verify data integrity by listing Flight Control resources (for example, devices and fleets) and comparing them to a known-good source.
  4. Confirm that the Red Hat Edge Manager API and web console behave as expected against the restored database.
  5. Record any gaps, errors, and corrective actions in your runbooks.

1.4. Recommended practices

Follow these practices to complement your PostgreSQL database backups for Red Hat Edge Manager on Red Hat Enterprise Linux.

  • Git-backed configuration: Store declarative configuration in Git and sync it with the control plane using Repository resources and gitRef in 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.yaml and 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, see Additional resources.

Additional resources

Chapter 2. Restoring the PostgreSQL database for Red Hat Edge Manager on Red Hat Enterprise Linux

Use this topic after you have a backup of the flightctl database and need to recover Red Hat Edge Manager on Red Hat Enterprise Linux. A typical flightctl-services deployment runs application containers as systemd-managed Podman quadlets. During restore you must keep the PostgreSQL and KV store services running while application services are stopped: the primary procedure restores the database, runs flightctl-restore, then starts application services again. An alternative path skips flightctl-restore but still stops only application services while the database and KV remain up.

2.1. Prerequisites

The following items cover access, tooling, backups, and release compatibility for the restore procedures in this topic on a Red Hat Enterprise Linux host where Red Hat Edge Manager runs as systemd-managed Podman quadlets. The mandatory requirements apply to both the primary restore procedure and the database-only alternative. Optional tools listed later are needed only when you run the steps that use them (for example, temporary port publishing for flightctl-restore).

  • Host access: Root privileges or sudo on the host where the quadlets run, with permission to stop and start systemd units, run systemctl daemon-reload, create unit drop-in files under .d directories, and run Podman commands (including podman secret and podman exec).
  • Core tools: systemctl and podman installed and usable by your restore account.
  • Flight Control CLI tools: flightctl and flightctl-restore available on the host (or on a jump host if your runbook runs commands remotely). Before you restore, confirm that flightctl-restore matches the Red Hat Edge Manager server version.
  • Backup artifacts: A tested backup of the flightctl PostgreSQL database, in a form your team can replay (logical dump, physical backup, or other agreed method). Include matching configuration backups from /etc/flightctl/ when your recovery plan requires them.
  • Compatible versions: The Red Hat Edge Manager / flightctl-services release on the host should be compatible with the data in the backup (typically the same major release as when the backup was created).

Optional tools for verification steps in this topic (install only what you use):

  • jq — parse output from podman secret inspect when retrieving passwords.
  • pg_isready — check PostgreSQL readiness on localhost after temporary port publishing.
  • redis-cli (Red Hat Enterprise Linux 9) or valkey-cli (Red Hat Enterprise Linux 10) — check KV store connectivity on localhost; use the client that matches your host’s major Red Hat Enterprise Linux version and container image.
  • ss or netstat — confirm that ports 5432 and 6379 listen during the restore window.
Note

If Red Hat Edge Manager runs on Red Hat OpenShift Container Platform or another Kubernetes cluster rather than on a Red Hat Enterprise Linux quadlet host, prerequisites differ (for example, kubectl access and cluster networking). See This content is not included.Restoring the PostgreSQL database for Red Hat Edge Manager on Red Hat OpenShift Container Platform.

Important

Perform full restores during a maintenance window. Restoring data requires stopping application services and can interrupt device management until the procedure completes.

2.2. Restore using quadlets and flightctl-restore

Typical RPM installations run Red Hat Edge Manager application components as separate systemd units backed by Podman quadlets, while the PostgreSQL and KV store containers keep running until you intentionally restart them. This sequence matches that layout: stop application services only, restore the flightctl database, supply credentials, expose ports locally for flightctl-restore, run the restore binary, remove temporary port publishing, then start application services again.

  1. Verify that flightctl-restore matches the Red Hat Edge Manager server version: 

    flightctl version
flightctl-restore version
echo "Server version: $(flightctl version)"
echo "Restore version: $(flightctl-restore version)"
    Important

    The server and restore versions must match. Update the flightctl-restore binary before you continue if they differ.

  2. Stop the Red Hat Edge Manager application services so they do not write to the database during restore. Do not stop flightctl-db.service, flightctl-kv.service, or other database or KV units; they must keep running while you restore data and run flightctl-restore. 

    # Stop only application services (keep database and KV store running)
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

    If systemctl reports Unknown unit for a service, your host might not ship that component (for example, image builder or UI). Skip that line. Do not run systemctl stop flightctl.target here; that would stop the database and KV services as well.

  3. Confirm that the application units you stopped are inactive: 

    sudo systemctl status flightctl-api.service
systemctl is-active flightctl-api.service
  4. Restore the flightctl PostgreSQL database using the method that matches your backup (for example, pg_restore, psql with a SQL dump, or storage-level recovery). Ensure the database is consistent and reachable from the deployment before you run flightctl-restore.

  5. Retrieve the database application password from the Podman secret: 

    DB_APP_PASSWORD=$(sudo podman secret inspect flightctl-postgresql-user-password --showsecret | jq -r '.[0].SecretData')
echo "Database password retrieved successfully"

  6. Retrieve the KV store password from the Podman secret: 

    KV_PASSWORD=$(sudo podman secret inspect flightctl-kv-password --showsecret | jq -r '.[0].SecretData')
echo "KV store credentials retrieved successfully"

  7. Optional: verify database and KV connectivity from the host through the running containers:

    Database: verify readiness: 

    sudo podman exec flightctl-db pg_isready -U postgres

    To connect to the database for additional verification (optional): 

    sudo podman exec -it flightctl-db psql -U flightctl_app -d flightctl

    KV store: on Red Hat Enterprise Linux 9 you can use redis-cli; on Red Hat Enterprise Linux 10 use valkey-cli inside the container, for example: 

    sudo podman exec flightctl-kv redis-cli ping

  8. Publish the database and KV ports on localhost so flightctl-restore can reach them. The database and KV containers use a private network by default; use temporary systemd drop-in files to add port publishing, then reload and restart only those services: 

    DB_CONTAINER_FILE=$(systemctl show flightctl-db.service -p SourcePath --value)
KV_CONTAINER_FILE=$(systemctl show flightctl-kv.service -p SourcePath --value)
DB_DROPIN_DIR="${DB_CONTAINER_FILE}.d"
KV_DROPIN_DIR="${KV_CONTAINER_FILE}.d"
sudo mkdir -p "$DB_DROPIN_DIR" "$KV_DROPIN_DIR"

sudo tee "$DB_DROPIN_DIR/10-publish-port.conf" > /dev/null <<'EOF'
[Container]
PublishPort=5432:5432
EOF

sudo tee "$KV_DROPIN_DIR/10-publish-port.conf" > /dev/null <<'EOF'
[Container]
PublishPort=6379:6379
EOF

sudo systemctl daemon-reload
sudo systemctl restart flightctl-db.service flightctl-kv.service

    Verify listening ports and basic connectivity (adjust the KV client for your Red Hat Enterprise Linux major version): 

    ss -tlnp | grep -E ':5432|:6379' || true
pg_isready -h localhost -p 5432
REDISCLI_AUTH="$KV_PASSWORD" redis-cli -h localhost -p 6379 ping

    On Red Hat Enterprise Linux 10, use VALKEYCLI_AUTH with valkey-cli instead of REDISCLI_AUTH with redis-cli if that matches your environment.

  9. Run flightctl-restore with the database and KV passwords (run from the directory that contains the binary if you do not use a full path): 

    DB_PASSWORD="$DB_APP_PASSWORD" KV_PASSWORD="$KV_PASSWORD" ./bin/flightctl-restore

    Watch the output for errors or successful completion.

  10. Remove the temporary port publishing drop-ins and restart the database and KV services: 

    DB_CONTAINER_FILE=$(systemctl show flightctl-db.service -p SourcePath --value)
KV_CONTAINER_FILE=$(systemctl show flightctl-kv.service -p SourcePath --value)
DB_DROPIN_DIR="${DB_CONTAINER_FILE}.d"
KV_DROPIN_DIR="${KV_CONTAINER_FILE}.d"
sudo rm -f "$DB_DROPIN_DIR/10-publish-port.conf" "$KV_DROPIN_DIR/10-publish-port.conf"
sudo rmdir "$DB_DROPIN_DIR" 2>/dev/null || true
sudo rmdir "$KV_DROPIN_DIR" 2>/dev/null || true
sudo systemctl daemon-reload
sudo systemctl restart flightctl-db.service flightctl-kv.service

  11. Start the application services again (same set you stopped; omit units your host does not use): 

    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

    Verify with sudo systemctl status on each unit and sudo podman ps --filter "name=flightctl-".

  12. Confirm that the API responds and that inventory looks correct in the Red Hat Edge Manager web console or with flightctl CLI commands.

2.3. Alternative: Database-only restore without flightctl-restore

If your operations team restores the PostgreSQL data without running flightctl-restore (for example, a DBA-led replay into the live database), use the same rule as the main procedure: stop only application services so the database and KV store keep running. Do not use systemctl stop flightctl.target, which stops flightctl-db, flightctl-kv, and everything else.

  1. Stop the application services only (same list as in the Restore using quadlets and flightctl-restore procedure, step 2). Skip units that do not exist on your host.

  2. Restore the flightctl database 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 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.

2.4. After you restore

When the restore commands finish and application services are healthy again, validate the control plane and plan for device reconciliation. Restoring the database changes what the service knows about devices; edge devices must reconnect and compare their live state to the restored specifications.

Operational follow-up

  • Re-run checks from the Testing backups section in the backup topic if you need a structured validation checklist. See Additional resources.
  • Record commands, secret handling, and timing in your runbooks so the next restore repeats cleanly.

2.5. Post-restore device status changes

After a successful restore, devices move through automatic status transitions while they reconnect and reconcile with the restored control plane data.

AwaitingReconnect
Devices are always placed in AwaitingReconnect first. The service waits for each device to report its current state again. Spec reconciliation for those devices remains paused until they reconnect.
Enrollment requests and post-restore approval

Devices approved after the restored backup was taken do not exist after the restore and must be approved again. After restore:

  • Devices created from a restored enrollment request are placed in AwaitingReconnect and follow the normal AwaitingReconnect behavior.
  • Devices without an enrollment request before backup, with a non-zero deployed specification version, are placed in AwaitingReconnect and follow the normal AwaitingReconnect behavior.
  • Devices without an enrollment request before backup, with a zero specification version, move to normal status.
ConflictPaused
After a device reconnects and reports its current state, the service compares the specification stored in the restored backup with the device-reported version. If the restored backup specification is older (for example, the device had moved forward while backups lagged), the device can enter ConflictPaused. Rendering of new specifications stops for that device until an operator resolves the mismatch. Human review is required before you force configuration forward.
Normal operation
When the restored specification and the device-reported state are compatible, the device returns to normal operational statuses (for example, online or updating) and usual reconciliation resumes.

Monitor device status

Use the flightctl CLI to see which devices need attention: 

flightctl get devices
flightctl get devices --field-selector=status.summary.status=AwaitingReconnect
flightctl get devices --field-selector=status.summary.status=ConflictPaused

Resolve ConflictPaused devices

  1. Review the specification source: if the device belongs to a fleet, inspect the fleet template and selector; if not, inspect the device spec directly. Review labels and ownership to confirm how the restored specification applies to the device.

  2. When you are confident the restored specification is what you want, resume the device or a group of devices. Replace example-device with your device resource name and adjust selectors to match your environment: 

    flightctl resume device example-device
flightctl resume device --selector="environment=production"

    Use additional flightctl resume device options your deployment supports (for example, field selectors) if you need to resume many devices in bulk.

Additional resources

Chapter 3. Backing up the PostgreSQL database for Red Hat Edge Manager on Red Hat OpenShift Container Platform

This topic describes PostgreSQL backup strategy for Red Hat Edge Manager on Red Hat OpenShift Container Platform: recovery point objectives (RPOs), database backup scope, how to validate restores, and practices that complement database backups in a cluster deployment.

3.1. Overview

Red Hat Edge Manager uses PostgreSQL to store mission-critical data, including device configurations, fleet management records, user profiles, and system state. To protect this data and ensure business continuity, implement backup strategies that support disaster recovery.

Define your Recovery Point Objective (RPO) based on 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
Important

You are responsible for implementing and managing your own backup strategies for the PostgreSQL database. Red Hat Edge Manager documents architectural guidance and best practices; it does not manage backups for your deployment.

3.2. Database backup scope

To ensure a full system recovery, back up the flightctl database, including the following:

  • Data: Devices, fleets, organizations, templates, and related records
  • Schema and structure: The database architecture and table definitions that match your installed Red Hat Edge Manager release
  • Security metadata: Database users, roles, and access permissions required for the application

3.3. Testing backups

Regularly test backup and restore procedures. Untested backups are a common source of failed recoveries.

  1. Create an isolated test environment that mirrors your production configuration closely enough to exercise a restore (same major Red Hat Edge Manager version and similar configuration).
  2. Restore from your most recent backup into the test environment using your chosen restore procedure.
  3. Verify data integrity by listing Flight Control resources (for example, devices and fleets) and comparing them to production records.
  4. Confirm that the Red Hat Edge Manager API and web console behave as expected against the restored database.
  5. Record any gaps, errors, and corrective actions in your runbooks.

3.4. Recommended practices

Follow these practices to complement your PostgreSQL database backups for Red Hat Edge Manager on Red Hat OpenShift Container Platform.

  • Git-backed configuration: Store declarative configuration in Git. Use the Repository resource to reference configurations with gitRef in 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 on external services (for example, GitHub, GitLab, or Bitbucket) in a different failure domain than the cluster that runs Red Hat Edge Manager.
  • Back up deployment configuration: Regularly back up Helm values files and related configuration manifests so you can redeploy consistently.
  • Version and tag changes: Tag and version configuration changes so you can roll back or redeploy predictably.

Chapter 4. Restoring the PostgreSQL database for Red Hat Edge Manager on Red Hat OpenShift Container Platform

After you lose data or need to recover the control plane database on Red Hat OpenShift Container Platform, restore the flightctl PostgreSQL database and related state using the backup artifacts and methods that match your backup scope. This topic walks through scaling workloads, running flightctl-restore, and bringing services back. Exact database restore commands before flightctl-restore still depend on your backup format and tooling.

4.1. Prerequisites

The following prerequisites apply to the restore procedure for Red Hat Edge Manager on Red Hat OpenShift Container Platform.

  • Cluster access to the Kubernetes cluster that hosts the Red Hat Edge Manager deployment.
  • The OpenShift project (Kubernetes namespace) where you installed the Red Hat Edge Manager Helm chart. The examples in this topic use the placeholder rhem-chart-namespace; substitute your real namespace name everywhere it appears (production deployments often use a single namespace for all Red Hat Edge Manager workloads).
  • Kubernetes tools: kubectl installed and configured with administrative permissions.
  • Flight Control CLI: flightctl and flightctl-restore available locally or in your restore environment.
  • Backup artifacts: access to the database backup files required for recovery.
  • Optional verification tools: redis-cli and pg_isready for validating service readiness and data integrity.
Important

Database restore steps before you run flightctl-restore must match your backup strategy (for example, pg_restore, psql, or volume-level recovery). Follow your organization’s runbooks together with the outline below.

4.2. Restore procedure

Use this procedure to restore the flightctl PostgreSQL database for Red Hat Edge Manager on Red Hat OpenShift Container Platform.

  1. Verify that the flightctl-restore version matches the Red Hat Edge Manager server version:

    1. Run the following command for the flightctl version: 

      flightctl version

    2. Run the following command for the flightctl-restore version: 

      flightctl-restore version

    3. Confirm that the server version and the restore version are the same: 

      echo "Server version: $(flightctl version)"
echo "Restore version: $(flightctl-restore version)"
      Important

      The server version and restore version must match exactly. If they do not match, update your flightctl-restore binary to align with the server version before proceeding.

  2. Scale down the Red Hat Edge Manager services to avoid data conflicts during the restore process. On Red Hat OpenShift Container Platform, all of these workloads run in a single OpenShift project; use the same namespace value on every command (the placeholder rhem-chart-namespace stands for that project—replace it with yours): 

    # Replace rhem-chart-namespace with your OpenShift project (one namespace for all deployments below)
kubectl scale deployment flightctl-api --replicas=0 -n rhem-chart-namespace
kubectl scale deployment flightctl-worker --replicas=0 -n rhem-chart-namespace
kubectl scale deployment flightctl-periodic --replicas=0 -n rhem-chart-namespace
kubectl scale deployment flightctl-alert-exporter --replicas=0 -n rhem-chart-namespace
kubectl scale deployment flightctl-alertmanager-proxy --replicas=0 -n rhem-chart-namespace

    Wait for pods to terminate, then verify: 

    # Same namespace as above
kubectl get pods -n rhem-chart-namespace

  3. Restore the flightctl PostgreSQL database from your existing backup.

    After all Red Hat Edge Manager services are scaled down, restore the database using the method that matches your backup strategy.

    • Target database: Restore the PostgreSQL database instance named flightctl.
    • Supported methods: Use your preferred recovery procedure, such as pg_restore, psql (for SQL dumps), or infrastructure-level volume snapshots.
    • Verification: Confirm that the database is fully accessible and that the integrity of the restored data is verified before proceeding.
    Important

    The specific restoration commands depend on your backup strategy and tooling. Ensure the database is fully restored and consistent before you continue.

  4. Retrieve database and KV store credentials (same namespace as the scale commands): 

    DB_APP_PASSWORD=$(kubectl get secret flightctl-db-app-secret -n rhem-chart-namespace -o jsonpath='{.data.userPassword}' | base64 -d)

echo "Database password retrieved successfully"
    KV_PASSWORD=$(kubectl get secret flightctl-kv-secret -n rhem-chart-namespace -o jsonpath='{.data.password}' | base64 -d)

  5. Set up port forwarding for the database and the KV store. Use separate terminal sessions for each port forward, or run them in the background.

    Forward the database service: 

    # Forward database port (run in a separate terminal or in the background)
kubectl port-forward svc/flightctl-db 5432:5432 -n rhem-chart-namespace &
DB_PORT_FORWARD_PID=$!

# Verify database connectivity (if available)
pg_isready -h localhost -p 5432

    Forward the KV store service: 

    # Forward KV store port (run in a separate terminal or in the background)
kubectl port-forward svc/flightctl-kv 6379:6379 -n rhem-chart-namespace &
KV_PORT_FORWARD_PID=$!

# Verify KV store connectivity (if available)
REDISCLI_AUTH="$KV_PASSWORD" redis-cli -h localhost -p 6379 ping

  6. Run the restore command using environment variables for the database and KV store passwords: 

    DB_PASSWORD="$DB_APP_PASSWORD" KV_PASSWORD="$KV_PASSWORD" ./bin/flightctl-restore

    Monitor the restore output for errors or completion messages.

  7. Stop the port-forward processes when the restore finishes: 

    kill $DB_PORT_FORWARD_PID $KV_PORT_FORWARD_PID

    If you ran the port forwards in separate terminals instead, stop them with Ctrl+C in those terminals.

  8. Restart Red Hat Edge Manager services. Scale the deployments back to their normal replica counts in the same OpenShift project as in step 2: 

    # Replace rhem-chart-namespace with your OpenShift project (same single namespace for every command)
kubectl scale deployment flightctl-api --replicas=1 -n rhem-chart-namespace
kubectl scale deployment flightctl-worker --replicas=1 -n rhem-chart-namespace
kubectl scale deployment flightctl-periodic --replicas=1 -n rhem-chart-namespace
kubectl scale deployment flightctl-alert-exporter --replicas=1 -n rhem-chart-namespace
kubectl scale deployment flightctl-alertmanager-proxy --replicas=1 -n rhem-chart-namespace
kubectl get deployments -n rhem-chart-namespace
kubectl get pods -n rhem-chart-namespace

4.3. After you restore

When the restore finishes and Red Hat Edge Manager workloads are healthy again in your Red Hat OpenShift Container Platform namespace, validate the control plane and plan for device reconciliation. Restoring the database changes what the service knows about devices; edge devices must reconnect and compare their live state to the restored specifications.

Operational follow-up

  • Re-run any validation steps from the Testing backups section in the backup topic if you need a structured checklist. See Additional resources.
  • Document deviations, incidents, and command variants in your runbooks so the next restore follows the same path.

4.4. Post-restore device status changes

After a successful restore, devices move through automatic status transitions while they reconnect and reconcile with the restored control plane data.

AwaitingReconnect
Devices are always placed in AwaitingReconnect first. The service waits for each device to report its current state again. Spec reconciliation for those devices remains paused until they reconnect.
Enrollment requests and post-restore approval

Devices approved after the restored backup was taken do not exist after the restore and must be approved again. After restore:

  • Devices created from a restored enrollment request are placed in AwaitingReconnect and follow the normal AwaitingReconnect behavior.
  • Devices without an enrollment request before backup, with a non-zero deployed specification version, are placed in AwaitingReconnect and follow the normal AwaitingReconnect behavior.
  • Devices without an enrollment request before backup, with a zero specification version, move to normal status.
ConflictPaused
After a device reconnects and reports its current state, the service compares the specification stored in the restored backup with the device-reported version. If the restored backup specification is older (for example, the device had moved forward while backups lagged), the device can enter ConflictPaused. Rendering of new specifications stops for that device until an operator resolves the mismatch. Human review is required before you force configuration forward.
Normal operation
When the restored specification and the device-reported state are compatible, the device returns to normal operational statuses (for example, online or updating) and usual reconciliation resumes.

Monitor device status

Use the flightctl CLI to see which devices need attention: 

flightctl get devices
flightctl get devices --field-selector=status.summary.status=AwaitingReconnect
flightctl get devices --field-selector=status.summary.status=ConflictPaused

Resolve ConflictPaused devices

  1. Review the specification source: if the device belongs to a fleet, inspect the fleet template and selector; if not, inspect the device spec directly. Review labels and ownership to confirm how the restored specification applies to the device.

  2. When you are confident the restored specification is what you want, resume the device or a group of devices. Replace example-device with your device resource name and adjust selectors to match your environment: 

    flightctl resume device example-device
flightctl resume device --selector="environment=production"

    Use additional flightctl resume device options your deployment supports (for example, field selectors) if you need to resume many devices in bulk.

Additional resources

Legal Notice

Copyright © Red Hat.
Except as otherwise noted below, the text of and illustrations in this documentation are licensed by Red Hat under the Creative Commons Attribution–Share Alike 3.0 Unported license . If you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, the Red Hat logo, JBoss, Hibernate, and RHCE are trademarks or registered trademarks of Red Hat, LLC. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
XFS is a trademark or registered trademark of Hewlett Packard Enterprise Development LP or its subsidiaries in the United States and other countries.
The OpenStack® Word Mark and OpenStack logo are trademarks or registered trademarks of the Linux Foundation, used under license.
All other trademarks are the property of their respective owners.