Procedure

1. Confirm that flightctl and flightctl-backup match the running Red Hat Edge Manager server:

   Run flightctl version when the CLI can reach the Red Hat Edge Manager API (use flightctl login if needed) so you can compare Client Version, Server Version, and flightctl-backup version. For more information about prerequisites for backup and restore, see Additional resources.

   flightctl version
   flightctl-backup version

   Copy code to clipboard

2. Create a backup directory owned by the user that runs the command (example path):

   sudo mkdir -p /var/backups/rhem
   sudo chown "$(whoami)" /var/backups/rhem

   Copy code to clipboard

3. Run the backup. Use --output to set the destination directory and --config only if your service configuration is not in the default location:

   flightctl-backup --output /var/backups/rhem

   Copy code to clipboard

   Optional: specify a custom service configuration path:

   flightctl-backup --output /var/backups/rhem --config /etc/flightctl/service-config.yaml

   Copy code to clipboard
   Note

   If --config is not specified, the default path /etc/flightctl/service-config.yaml is used.

4. Verify that the command created a timestamped archive and checksum file:

   ls -l /var/backups/rhem/flightctl-backup-*.tar.gz*
   sha256sum -c /var/backups/rhem/flightctl-backup-*.tar.gz.sha256

   Copy code to clipboard
5. Copy the archive and checksum to backup storage outside the host failure domain.

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

   Copy code to clipboard

   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

   Copy code to clipboard

   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-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

   Copy code to clipboard
   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 (for example, when the command connects to local services), 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

   Copy code to clipboard

   Monitor the command output until it completes successfully. flightctl-restore is not transactional: a mid-run failure can leave the deployment partially restored (for example, KV store cleared before all device annotations are updated). 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

   Copy code to clipboard
6. Confirm API health and review device status in the console or CLI.

Procedure

1. Set the namespace variable for your deployment (replace rhem-chart-namespace):

   export RHEM_NS=rhem-chart-namespace
   kubectl config set-context --current --namespace="$RHEM_NS"

   Copy code to clipboard

2. Confirm that flightctl and flightctl-backup match the Red Hat Edge Manager deployment:

   Run flightctl version when the CLI can reach the Red Hat Edge Manager API (use flightctl login if needed) so you can compare Client Version, Server Version, and flightctl-backup version. For more information about prerequisites for backup and restore, see Additional resources.

   flightctl version
   flightctl-backup version

   Copy code to clipboard

3. Run the backup:

   mkdir -p "$HOME/rhem-backups"
   flightctl-backup --output "$HOME/rhem-backups"

   Copy code to clipboard

   The command detects the Kubernetes deployment, dumps the internal database when applicable, exports PKI Secrets and the service ConfigMap, and captures Helm values used for the release.

4. Verify the archive and checksum:

   ls -l "$HOME/rhem-backups"/flightctl-backup-*.tar.gz*
   sha256sum -c "$HOME/rhem-backups"/flightctl-backup-*.tar.gz.sha256

   Copy code to clipboard
5. Copy the archive pair to storage outside the cluster failure domain.

Procedure

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

   From a workstation where flightctl is configured to reach the Red Hat Edge Manager API, run flightctl version (use flightctl login first 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

   Copy code to clipboard

   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 you scale down workloads. 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

   Copy code to clipboard

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

3. Scale down application deployments in the Red Hat Edge Manager namespace (replace rhem-chart-namespace):

   export RHEM_NS=rhem-chart-namespace
   kubectl scale deployment flightctl-api --replicas=0 -n "$RHEM_NS"
   kubectl scale deployment flightctl-worker --replicas=0 -n "$RHEM_NS"
   kubectl scale deployment flightctl-periodic --replicas=0 -n "$RHEM_NS"
   kubectl scale deployment flightctl-alert-exporter --replicas=0 -n "$RHEM_NS"
   kubectl scale deployment flightctl-alertmanager-proxy --replicas=0 -n "$RHEM_NS"
   kubectl get pods -n "$RHEM_NS"

   Copy code to clipboard

4. Run restore with the archive path. When the command needs database and KV access from your workstation, retrieve Secrets and use port-forwarding as documented in the manual PostgreSQL restore procedure on Red Hat OpenShift Container Platform. For more information about the restore procedure (manual database steps), see Additional resources. Then pass credentials:

   DB_APP_PASSWORD=$(kubectl get secret flightctl-db-app-secret -n "$RHEM_NS" -o jsonpath='{.data.userPassword}' | base64 -d)
   KV_PASSWORD=$(kubectl get secret flightctl-kv-secret -n "$RHEM_NS" -o jsonpath='{.data.password}' | base64 -d)
   export DB_PASSWORD="$DB_APP_PASSWORD" KV_PASSWORD="$KV_PASSWORD"
   flightctl-restore /path/to/flightctl-backup-YYYYMMDDTHHMMSSZ.tar.gz

   Copy code to clipboard

   Monitor the command output until it completes successfully. flightctl-restore is not transactional: a mid-run failure can leave the deployment partially restored (for example, KV store cleared before all device annotations are updated). Do not scale deployments back up until restore finishes without error.

   Important

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

   Note

   Apply Helm values from the archive manually if the restore output directs you to config/helm-values.yaml in the extracted layout. Your runbook should match the version of flightctl-restore you are running.

5. Scale deployments back to their normal replica counts:

   kubectl scale deployment flightctl-api --replicas=1 -n "$RHEM_NS"
   kubectl scale deployment flightctl-worker --replicas=1 -n "$RHEM_NS"
   kubectl scale deployment flightctl-periodic --replicas=1 -n "$RHEM_NS"
   kubectl scale deployment flightctl-alert-exporter --replicas=1 -n "$RHEM_NS"
   kubectl scale deployment flightctl-alertmanager-proxy --replicas=1 -n "$RHEM_NS"
   kubectl get pods -n "$RHEM_NS"

   Copy code to clipboard
6. Validate the API, console, and device inventory.

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 flightctl-restore with a flightctl-backup archive, or using your chosen database-only 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. Verify that flightctl-restore matches the Red Hat Edge Manager server version:

   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

   Copy code to clipboard

   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. 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-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

   Copy code to clipboard
   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

   Copy code to clipboard
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"

   Copy code to clipboard

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"

   Copy code to clipboard

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

   Copy code to clipboard

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

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

   Copy code to clipboard

   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

   Copy code to clipboard

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

   Copy code to clipboard

   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

   Copy code to clipboard

   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

   Copy code to clipboard

   Monitor the command output until it completes successfully. If it 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 remove port publishing or start application services.

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

    Copy code to clipboard

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
    sudo systemctl start flightctl-gateway.service

    Copy code to clipboard

    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.

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.

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"

   Copy code to clipboard

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

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 flightctl-restore with a flightctl-backup archive, or using your chosen database-only 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.

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

   From a workstation where flightctl is configured to reach the Red Hat Edge Manager API, run flightctl version (use flightctl login first 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

   Copy code to clipboard

   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. 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

   Copy code to clipboard

   Wait for pods to terminate, then verify:

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

   Copy code to clipboard

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"

   Copy code to clipboard

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

   Copy code to clipboard

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

   Copy code to clipboard

   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

   Copy code to clipboard

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

   Copy code to clipboard

   Monitor the command output until it completes successfully. If it fails or logs per-device KV errors, keep workloads scaled to zero. For more information about recovering from a failed or partial restore, see Additional resources before you stop port-forwards or scale services back up.

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

   kill $DB_PORT_FORWARD_PID $KV_PORT_FORWARD_PID

   Copy code to clipboard

   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

   Copy code to clipboard

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"

   Copy code to clipboard

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