Leapp Upgrade vs Clean Reinstall for AlmaLinux Host Data Preservation

Decision first

For a single AlmaLinux host, the viable path is decided by the leapp pre-upgrade inhibitor report and the current supported source-target pair. If the report shows only removable-package or third-party repository inhibitors that can be cleared, an in-place leapp upgrade can proceed with a full backup and rollback plan. If the report contains unresolved environment-dependent hard stops, a clean reinstall is the more reliable way to reach a supported major release, provided critical data and configuration are inventoried, backed up, and validated before reinstall.

Confirmed facts

• Leapp preupgrade produces a host-specific inhibitor report. Some inhibitors are resolvable by removing unsupported packages or disabling third-party repositories; others are hard stops that documentation cannot predict.
• A clean reinstall gives a supported baseline but preserves nothing by default. /etc, /var/lib, database data directories, web roots and custom tuning must be explicitly backed up and restored.
• AlmaLinux leapp supported source and target release pairs are version-sensitive and shift with point releases. The eligible pair must be confirmed before planning.

Likely explanation

Whether all inhibitors can be resolved safely is host-specific. General guidance cannot guarantee resolution without seeing the actual report categories, e.g., kernel variants, custom SELinux policies, or third-party repos that conflict with the target release. Data preservation is not automatic on either path: leapp keeps the filesystem in place but can fail mid-upgrade leaving the host unbootable; a reinstall requires a complete, tested backup to avoid silent loss of hidden configuration.

Steps needed for this case

1. Verify upgrade eligibility

1. Confirm installed leapp version and the documented supported source to target AlmaLinux major release pair for that version.
2. Run a preupgrade check on the host and capture the inhibitor report. Review each inhibitor for type: removable package, disabled repo, or environment hard stop.

2. If inhibitors are resolvable

• Take a full system backup with a tested rollback plan before any change.
• Remediate only inhibitors tied to removable packages or repositories, re-run preupgrade, and ensure zero blocking inhibitors remain.

3. If inhibitors cannot be fully resolved

1. Inventory critical paths: /etc, /var/lib, application data, database data directories, web roots, and tuned files.
2. Back up those paths and perform a test restore to a spare system.
3. Reinstall to the target release, then restore configuration and data, and validate service status and checksums against the pre-upgrade inventory.

Assumption and uncertainty: Recommendation depends on the actual inhibitor categories and the exact source and target releases. Without the preupgrade report summary and the confirmed supported release pair, the safety of an in-place upgrade cannot be assured.

Missing diagnostic detail that changes recommendation: the source AlmaLinux major version, target major version, and a summary of blocking inhibitor types from the host’s leapp preupgrade report.