使用Leapp工具将RHEL 7升级到RHEL 8时，系统会在升级开始前自动为根逻辑卷创建一个快照。如果升级过程中出现断电、软件包冲突、依赖错误等问题导致升级中断或升级后系统无法正常启动，就可以利用这个快照把系统完整地回滚到升级前的状态。很多运维人员在遇到升级失败时直接重装系统，其实掌握了快照回滚的思路，可以在十几分钟内恢复业务。本文结合实际操作，完整梳理回滚的处理流程和注意事项。
一、Leapp升级失败的常见原因
在讲回滚之前，先了解一下升级为什么会失败，有助于判断现场情况。Leapp升级的本质是在原系统上安装RHEL 8的软件包并替换系统核心组件，这个过程涉及数千个RPM包的替换，任何一个环节出问题都可能中断升级。常见的失败原因主要有以下几类。
第一类是软件包冲突。系统里如果安装了Red Hat官方仓库之外的第三方软件包，比如某些监控Agent、数据库驱动、自编译的内核模块，Leapp在预检阶段或者升级阶段就可能因为依赖无法解析而报错。第二类是磁盘空间不足。升级过程需要下载大量RPM包，同时在/boot分区和根分区上都要预留空间，如果/boot只分了200MB，大概率会失败。第三类是多内核共存问题，Leapp要求系统只保留一个待升级的内核版本，多余的内核需要提前卸载。第四类是升级过程中断电或强制的系统重启，导致RPM数据库损坏，系统启动时卡在emergency mode。
判断升级是否失败比较直观：如果机器重启后无法进入系统，或者进入系统后leapp相关服务持续报错、软件包版本混杂（一部分是el7一部分是el8），就需要考虑回滚了。切忌在失败状态下反复尝试重新升级，那样会让系统状态越来越混乱。
二、回滚的核心原理：快照合并
Leapp在升级开始前会执行leapp upgrade命令，此时它会检查根文件系统所在的逻辑卷类型。如果根分区是LVM逻辑卷，Leapp会自动创建一个只读快照，快照大小默认根据根分区空闲空间自动计算。升级实际是在原逻辑卷上进行的，快照保存的是升级前的原始数据。
回滚的原理就是利用LVM的lvconvert --merge功能：把快照中保存的旧数据反向合并回原逻辑卷。合并操作会把逻辑卷恢复到创建快照那一刻的状态，也就是升级前的RHEL 7系统。需要注意，合并操作不能在逻辑卷处于活跃挂载状态时立即生效，通常会在下一次激活该逻辑卷时（也就是重启过程中）执行合并，机器重启后就回到了升级前的系统。
这里有一个前提条件要确认：只有升级失败且快照没有被删除的情况下才能走这条路。如果升级成功后手动删除了快照，或者最初升级时根分区不是LVM，就没有快照可回滚，只能靠备份恢复。所以升级前确认根分区是LVM管理非常重要，执行下面的命令确认：
# 查看根分区是否为LVM逻辑卷 df -h / # 输出类似 /dev/mapper/rhel-root ... 说明是LVM # 查看Leapp创建的快照 lvs # 快照卷一般命名为 root-upgrade 或类似名称，attr列带s标志
三、完整回滚操作步骤
升级失败后机器通常处于两种状态：一种是还能启动到emergency模式或 Rescue 环境，另一种是完全无法启动只能进救援盘。两种情况的处理方式类似，下面以能进入emergency模式为例演示。
第一步，重启机器，在GRUB菜单界面选择带snapshot字样的引导项。Leapp升级时会在GRUB中自动添加一个快照引导条目，选择它可以从快照环境启动。如果GRUB菜单没有显示，开机时连续按Esc或上下方向键调出。选择快照引导项启动后，系统会以只读方式挂载快照中的原系统。
第二步，进入系统后确认快照逻辑卷存在，然后执行合并命令：
# 确认快照卷存在 lvs # 执行快照合并，卷名根据实际输出调整 lvconvert --merge /dev/rhel/root-upgrade # 系统会提示合并将在下次激活逻辑卷时进行 # Changing logical volume ... to merged # Merging of snapshot rhel/root-upgrade will occur on next activation
第三步，重建引导配置。由于升级过程中GRUB配置被改写过，回滚后需要确保引导项指向正确的内核。如果当前能进入系统，执行grub2-mkconfig -o /boot/grub2/grub.cfg重新生成配置；对于UEFI系统则输出到/boot/efi/EFI/redhat/grub.cfg。如果系统完全无法启动，需要用RHEL 7的安装光盘或救援模式启动，执行chroot切换到真实根分区后再做同样的操作。
第四步，重启机器。重启过程中LVM会自动执行快照合并，根据根分区数据量大小，合并可能需要几分钟到几十分钟，期间不要断电。合并完成后系统启动，进入的就是升级前的RHEL 7环境，之前安装的软件、配置、数据全部保留。
四、回滚后的验证与预防措施
回滚完成后不要急着重新升级，先做几项验证。确认系统版本是否回到RHEL 7，执行cat /etc/redhat-release查看；确认关键业务服务是否正常，比如数据库、中间件、Web服务的状态；确认网络配置是否正常，Leapp升级过程中可能改写过网络配置文件，回滚后要检查/etc/sysconfig/network-scripts/下的配置。还要检查/var/log/leapp/目录下的日志文件，里面记录了升级失败的具体原因，是排查问题的关键材料。
如果要再次尝试升级，务必先解决上次失败的原因。建议按以下清单逐项检查：运行leapp preupgrade做预检，认真处理每一项Inhibitor级别的报告；清理第三方仓库和冲突软件包；确保/boot分区至少500MB以上空间，根分区空闲空间不少于总容量的20%；只保留一个内核版本；升级前做好完整备份，包括/etc目录、数据库数据和关键业务配置。条件允许的话，先在测试环境完整演练一遍升级流程，确认无误后再操作生产环境。
另外提醒一点，Leapp的快照机制只保护升级失败的场景，它不是长期备份方案。快照会占用卷组空间，如果确定升级成功，可以执行lvremove删除快照释放空间。反过来，只要升级结果没有确认稳定运行一段时间，就不要急着删快照，保留它等于保留了一条后路。生产环境的大版本升级永远是风险操作，宁可多花时间在预检和备份上，也不要在失败后手忙脚乱。