在CentOS 8及以上版本中，dnf命令已经取代了老旧的yum，成为默认的包管理工具。当你执行了一次dnf update或者dnf install操作后，发现系统出现了兼容性问题、服务无法启动或者内核版本不对等情况，最直接有效的回滚方式就是使用dnf history命令。具体操作就是：先执行dnf history查看历史操作记录，找到对应的Transaction ID，然后用dnf history undo <ID>即可回滚到该操作之前的状态。整个过程通常在几分钟内就能完成，不需要重装系统，也不需要手动卸载软件包。
很多运维人员在CentOS 7时代习惯了yum history，升级到CentOS 8/Stream后发现命令变了，但逻辑完全一致。dnf history的核心作用就是记录每一次包管理操作的详细信息，包括安装了什么、升级了什么、删除了什么，并且支持精准回滚到任意一次操作之前。这篇文章会把从查看记录、分析问题、执行回滚到验证结果的全流程讲透，同时补充一些容易踩坑的注意事项。
一、dnf history命令的基本用法和输出解读要回滚操作，第一步当然是查看历史记录。直接在终端输入以下命令：
dnf history
执行后会输出类似下面的内容：
ID | Command line | Date and time | Action(s) | Altered ---+--------------------------+------------------+----------------+-------- 4 | install nginx | 2024-01-15 10:30 | Install | 12 3 | update | 2024-01-14 08:00 | Update | 45 2 | remove httpd | 2024-01-13 15:20 | Erase | 3 1 | install vim wget curl | 2024-01-12 09:00 | Install | 8
每一行代表一次操作。ID列是事务编号，Command line是你当时执行的命令，Date and time是操作时间，Action(s)是操作类型（Install安装、Update更新、Erase删除），Altered是受影响的包数量。你要回滚哪次操作，就记下对应的ID号。
如果你想查看某一次操作的具体细节，比如ID为3的update到底改了哪些包，可以用：
dnf history info 3
这会列出该次操作涉及的所有软件包名称、版本变化，方便你判断这次更新是不是导致问题的根源。
二、执行回滚操作的完整步骤确认了要回滚的Transaction ID之后，执行回滚命令：
dnf history undo 3
这里的3就是上面例子中update操作的ID。执行后dnf会自动计算需要撤销的包变更，并提示你确认。如果系统提示需要安装或卸载某些依赖包来完成回滚，按y确认即可。整个过程dnf会自动处理依赖关系，不需要你手动干预。
需要特别注意的一点是：undo操作本身也会被记录到history中，生成一个新的ID。比如你undo了ID 3，系统会生成一个新的ID 5，Action显示为Undo。这意味着如果回滚后发现问题没解决或者出现了新问题，你还可以继续undo这次回滚操作，相当于有了一个"后悔药中的后悔药"。
如果你想回滚到某个特定时间点之前的所有操作，可以使用：
dnf history undo last
这个命令会回滚最近一次操作。如果需要回滚更早的操作，就指定具体ID。如果要一次性回滚多个操作，可以用：
dnf history undo 2..4
这表示回滚ID从2到4的所有操作。不过实际生产环境中，建议一次只回滚一个ID，逐步排查，避免一次性回滚太多导致系统状态混乱。
三、回滚内核更新的特殊处理在所有回滚场景中，内核更新回滚是最常见也是最需要谨慎的。很多时候运维人员执行了dnf update后，新内核和硬件驱动或者某些内核模块不兼容，导致系统重启后无法正常进入。这时候用dnf history undo回滚内核包是第一选择。
但有一个关键问题：回滚内核后，grub引导菜单里可能仍然保留着旧内核的启动项，也可能新内核的启动项还在。建议回滚完成后手动检查grub配置：
grub2-set-default 0
或者查看当前默认启动项：
grub2-editenv list
确保系统下次重启时使用的是回滚后的正确内核版本。如果grub菜单里有多个内核选项，重启时手动选择旧版本也是一种保险做法。
另外，CentOS 8/Stream默认会保留最后三个内核版本。你可以通过以下命令查看已安装的内核：
rpm -qa | grep kernel
如果回滚后发现旧内核已经被自动清理掉了（虽然默认保留但某些情况下可能被清除），那就需要从CentOS镜像源重新安装对应版本的内核，这种情况就比较麻烦了。所以强烈建议在执行大范围update之前，先确认当前内核版本并做好记录。
四、回滚操作失败的常见原因和解决办法实际运维中，dnf history undo并不是百分之百成功的。以下几种情况会导致回滚失败或者出现异常：
第一种情况是依赖冲突。比如你要回滚的操作中包含了某个核心库的升级，而当前系统中其他已安装的软件依赖于这个新版库，回滚就会产生依赖冲突。dnf会报错提示，这时候你需要先处理冲突，可能需要同时回滚多个相关操作，或者手动卸载冲突包。
第二种情况是回滚了但服务状态异常。包虽然回滚了，但配置文件可能已经被新版本的软件修改过。比如nginx升级后配置文件格式变了，回滚到旧版本后旧版nginx读不懂新格式的配置文件，服务就起不来。解决办法是手动恢复配置文件备份，或者根据旧版本的格式要求重新编写配置。
第三种情况是history记录被清理。dnf的历史记录默认保存在/var/lib/dnf/history/目录下，如果你手动清理过这个目录或者执行过dnf clean all，历史记录就没了。所以建议在执行任何大操作之前，先把当前状态快照保存好，比如用rpm -qa导出已安装包列表：
rpm -qa > /root/package_list_before_update.txt
这样即使history丢了，你也有一份包清单可以参考。
五、生产环境中使用dnf history回滚的最佳实践在生产服务器上操作，不能像测试环境那样随意。以下是几条经过实战验证的建议：
首先，养成操作前记录的习惯。每次执行dnf update或dnf install之前，先运行：
dnf history > /root/dnf_history_before.txt rpm -qa > /root/rpm_list_before.txt
把这两个文件保存下来，万一出问题可以快速对比。
其次，不要在业务高峰期执行大范围更新。如果必须更新，选择维护窗口，并且提前准备好回滚方案。回滚命令本身执行很快，但回滚后可能需要重启服务，这个重启过程才是真正影响业务的环节。
第三，回滚完成后一定要验证。不要以为undo成功就万事大吉了。至少要检查以下几点：核心服务是否正常运行（systemctl status关键服务）、内核版本是否正确（uname -r）、网络是否正常（ping测试）、磁盘挂载是否正常（df -h和mount命令）。
第四，如果你使用的是CentOS Stream，要特别注意它是滚动更新模式，包更新频率比稳定版CentOS高很多，出问题的概率也更大。对于生产环境，建议优先使用CentOS 8的稳定分支或者迁移到Rocky Linux、AlmaLinux等兼容发行版。
六、dnf history和其他回滚手段的对比除了dnf history undo之外，CentOS上还有其他几种回滚方式，各有适用场景：
快照回滚：如果你的系统用的是LVM逻辑卷，可以在操作前创建快照，出问题后用lvconvert --merge回滚。这种方式是文件系统级别的完整回滚，比包级别的回滚更彻底，但前提是你提前做了快照。
手动卸载重装：对于单个包出问题的情况，直接用dnf remove卸载再dnf install指定版本也是一种办法。但这种方式不适合批量操作回滚，效率低且容易遗漏依赖。
系统备份恢复：如果是灾难性的问题，比如回滚失败导致系统无法启动，那就只能从备份恢复了。这也是为什么前面强调要做好快照和记录的原因。
综合来看，dnf history undo是最快速、最精准、最适合包管理层面回滚的方案，是CentOS运维人员必须熟练掌握的核心技能。
七、总结CentOS 8及Stream版本中，dnf history命令是运维人员处理包更新事故的第一道防线。查看记录用dnf history，查看详情用dnf history info <ID>，执行回滚用dnf history undo <ID>，回滚最近一次用dnf history undo last。操作简单，但要注意依赖冲突、配置文件兼容、内核引导等细节问题。生产环境中务必提前备份记录，回滚后全面验证，确保业务恢复正常。掌握这套流程，你在面对系统更新翻车时就能从容应对，而不是手忙脚乱地重装系统。
