内核升级的长期维护:升级、备份与迁移的顺序
回滚只需在 GRUB 里选旧内核,但被卸掉的模块包要先装回来才能进系统
把升级、备份、迁移这三件事流程化,才敢长期用。
先说结论
升级前先备份,备份后先演练恢复;不能回滚的升级不做。
- 固定版本,改动前记录当前版本号
- 升级前:备份数据 + 备份配置
- 升级后:验证核心功能,不只看进程
- 迁移:先迁数据,再迁流量
- 回滚方案写在纸上,别只存在脑子里
升级策略
uname -r 显示的是正在运行的内核,装完新内核不重启不会生效。
| 类型 | 频率 | 风险 | 做法 |
|---|---|---|---|
| 补丁版本 | 每月 | 低 | 直接升,保留旧镜像 |
| 次版本 | 每季 | 中 | 看变更日志,先在测试实例升 |
| 大版本 | 按需 | 高 | 读迁移指南,准备回滚 |
| 依赖升级 | 每季 | 中 | 锁版本,别用 latest |
备份的三层
三层分别是:数据备份、配置备份、以及「能重建这台机器」的文档。缺第三层,前两层迟早用不上。
这个服务的几个维护事实
和它自身机制相关的几条:
- 第三方驱动走 DKMS,内核一换就重编,编译失败时新内核起来没有网卡
- uname -r 显示的是正在运行的内核,装完新内核不重启不会生效
- 自定义启动参数写在 /etc/default/grub,改完要 update-grub 才进菜单
- /boot 只给 200MB 时,第三个内核装到一半就报 No space left on device

迁移的步骤
- 新机器按文档重建环境,验证空跑
- 同步数据,做一次一致性校验(条数、校验和)
- 切换前用 hosts 指向新机器验证
- 切换 DNS 或反代,保留旧机器一周
- 观察日志与错误率,再决定是否下线旧机
维护日历
每月:看磁盘与日志;每季:升级 + 备份校验;每半年:恢复演练一次;每年:清理不再需要的服务。
还有几处容易忽略的
都是小地方,但出问题时往往就卡在这里。
- Debian/Ubuntu 升级内核会保留旧版本,/boot 里通常同时存在 2-3 个 vmlinuz
- 回滚只需在 GRUB 里选旧内核,但被卸掉的模块包要先装回来才能进系统
- 装完新内核直接重启,网卡没起来才发现驱动没编过
- 把 /boot 设成 200MB,两三次升级后内核装不下,dpkg 半配置状态
- 用 mainline 的 deb 包装非发行版内核,缺依赖后连救援模式都进不去
长期维护的秘诀很土:每次只改一件事,改完就验证。
评论 (3)
最小可用配置这个说法很好,先跑起来再优化。
「先看日志再猜」这句话值一篇文。
版本差异要强调,我照着做结果参数名全变了。
发表评论