What should a rollback drill prove before a major Rocky Linux upgrade?
A successful pre-upgrade check does not prove that the recovery path works. A system may boot after a failed upgrade while third-party repositories, kernel modules, storage mounts, SELinux policy, network configuration, or application data remain inconsistent. A VM snapshot is useful, but it may not cover external volumes or prove that restore time is acceptable.
A practical drill could preserve package and repository inventories, configuration, boot entries, encryption details, and application data; restore that material into an isolated clone; then verify the running kernel, failed units, mounts, network policy, AVC denials, scheduled jobs, monitoring, backups, and application health. For in-place upgrades, the plan also needs a clear point after which rollback means restoring the whole system rather than trying to reverse packages.
What do Rocky Linux operators test before approving a major-version upgrade? Which parts of a Leapp-based move are realistically reversible, and what recovery evidence do you keep until the upgraded host has survived reboots and a normal observation window?