Linux系统升级前须先评估、再备份、后验证：区分大小版本影响，查发布说明与兼容性，全盘备份关键目录及配置，测试环境验证全流程，制定含旧内核保留、Live修复盘和回滚脚本的应急方案。
Linux系统升级前必须做足准备，否则可能引发服务中断、配置丢失甚至系统无法启动。核心原则是：先评估、再备份、后验证。
确认升级类型和影响范围
区分是小版本更新（如 Ubuntu 22.04.3 → 22.04.4）还是大版本升级（如 CentOS 7 → CentOS 8 或 Rocky Linux 9），二者风险差异极大。小版本通常只修复安全与稳定性问题，影响较小；大版本则涉及内核、默认软件包、服务管理方式（systemd 变更）、文件路径甚至 ABI 兼容性变化。
- 查阅官方发布说明（Release Notes），重点关注“Breaking Changes”和“Deprecated Features”
- 检查当前运行的关键服务（数据库、Web 服务器、自定义守护进程）是否被明确支持新版本
- 确认硬件驱动（尤其是专有显卡、RAID 卡、网卡固件）在目标版本中仍有维护或可用替代方案
执行完整系统备份与快照
不能只备份 /home 或 /etc——系统级升级可能修改 /usr、/lib、/boot 等关键目录。物理机建议使用 dd 或 Clonezilla 创建全盘镜像；虚拟机务必在升级前打一致状态快照（确保应用已停写或数据库已刷盘）。
- 备份 /etc、/var/log、/var/www（若为 Web 服务器）、数据库数据目录（如 /var/lib/mysql）及对应配置
- 导出已安装包列表：
dpkg --get-selections > pkg-list-debian.txt（Debian/Ubuntu）或rpm -qa --qf '%{name}-%{version}-%{release}.%{arch}\n' > pkg-list-rhel.txt（RHEL/CentOS/Rocky） - 记录当前内核版本（
uname -r）、启动引导器状态（ls /boot、efibootmgr -v）、网络配置（ip a+cat /etc/netplan/*.yaml或/etc/sysconfig/network-scripts/ifcfg-*）
测试环境先行验证
严禁直接在生产环境执行未经验证的升级操作。应搭建与生产环境尽可能一致的测试环境（相同硬件抽象层、相同软件栈、相同配置管理工具如 Ansible/Puppet）。
- 在测试机上完整走一遍升级流程，观察日志（
/var/log/apt/history.log或/var/log/yum.log）、服务启停状态、定时任务执行结果 - 重点验证业务依赖项：SSL 证书自动续期是否正常、监控 Agent 是否上报、日志轮转是否触发、自定义 systemd service 文件是否仍生效
- 若使用容器（Docker/Podman），确认 runtime 和镜像基础层兼容性，避免因 glibc 或内核模块变更导致容器异常
制定回滚与应急响应步骤
升级失败时，快速恢复比排查原因更重要。需提前准备好可立即执行的回退路径。
- 保留至少一个旧内核（修改 GRUB 配置：设置
GRUB_DEFAULT=1并禁用自动删除旧内核，如 Ubuntu 中注释掉remove_old_kernel） - 准备最小化 Live USB 启动盘（如 Debian Live 或 SystemRescueCD），用于从外部挂载并修复引导、还原备份或重装引导器
- 编写简明回滚脚本：例如一键卸载最新内核、重装指定版本 kernel 包、还原 /etc 配置快照、重启关键服务，存放在非系统分区（如 /opt/rollback.sh）
不复杂但容易忽略——真正决定升级成败的，往往不是命令敲得对不对，而是有没有把“万一出错怎么办”想清楚、写下来、试过一遍。
