2. 恢复前置准备：确认当前系统状态、收集关键日志、备份当前损坏的镜像

升级中断了，系统起不来。这时候最忌讳的就是手忙脚乱地开始敲命令。

我见过不少同事，一看到报错就急着重启、急着回滚，结果把现场破坏得一干二净。最后连问题根因都找不到，只能重装系统——那损失可就大了。

所以，在动手恢复之前，我们必须做三件事：确认状态、收集日志、备份镜像。这三步走稳了，后面的恢复才有底气。

2.1 确认当前系统状态

先别管别的，登录到服务器上，看看系统到底卡在哪个阶段。

我个人习惯用以下命令快速摸清情况：

# 查看系统运行级别和当前状态
systemctl status

# 检查关键服务是否存活
systemctl list-units --state=failed

# 查看磁盘挂载情况，确认根分区和 /boot 是否正常
df -h

# 查看内存和 CPU 负载，排除资源耗尽导致的假死
free -m
top -bn1 | head -5

为什么要先做这些？因为很多时候，升级中断并不是镜像损坏，而是依赖服务没起来、磁盘满了、或者内核参数冲突。我遇到过好几次，所谓的“升级失败”其实只是 /var 分区写满了，导致脚本执行到一半卡住。清理一下空间，重新执行升级脚本就完事了。

我的经验： 如果系统还能通过 SSH 登录，优先用 journalctl -xe 查看最近的系统日志。这条命令能直接定位到升级脚本最后执行的步骤，比瞎猜快得多。

2.2 收集关键日志

确认系统还活着之后，下一步就是收集日志。日志是事故现场的监控录像，没有它，后面分析根因就是盲人摸象。

我建议收集以下几类日志：

日志类型	路径/命令	说明
系统日志	`/var/log/messages` 或 `journalctl`	记录内核、服务、硬件等通用信息
升级脚本日志	`/var/log/upgrade/` 或 `/tmp/upgrade*.log`	升级工具自身的输出，最直接的线索
内核日志	`dmesg`	查看驱动加载、硬件识别、内核 panic 信息
服务状态快照	`systemctl list-units --all`	记录中断瞬间所有服务的状态
网络配置	`ip addr`、`ss -tlnp`	确认网络是否正常，排除网络中断导致的升级失败

收集命令可以这样写：

# 创建日志收集目录
mkdir -p /tmp/recovery_logs_$(date +%Y%m%d_%H%M%S)

# 收集系统日志
cp /var/log/messages /tmp/recovery_logs_*/ 2>/dev/null
journalctl --since "1 hour ago" > /tmp/recovery_logs_*/journal_latest.log

# 收集升级相关日志
find /var/log -name "*upgrade*" -exec cp {} /tmp/recovery_logs_*/ \;
find /tmp -name "*upgrade*" -exec cp {} /tmp/recovery_logs_*/ \;

# 收集内核日志
dmesg > /tmp/recovery_logs_*/dmesg.log

# 收集服务状态
systemctl list-units --all > /tmp/recovery_logs_*/service_status.log

# 打包带走
tar czf /tmp/recovery_logs_$(hostname)_$(date +%Y%m%d_%H%M%S).tar.gz /tmp/recovery_logs_*/

注意： 日志收集一定要在任何恢复操作之前完成。我曾经因为先重启了服务，导致 journalctl 里的环形缓冲区被覆盖，关键报错信息再也找不回来了。那次排查花了整整两天，教训深刻。

2.3 备份当前损坏的镜像

日志收集完了，接下来就是备份。你可能会问：“镜像都损坏了，备份还有意义吗？”

有，而且意义很大。损坏的镜像本身就是一个重要的参考点。万一后面的恢复操作把现场搞得更乱，至少还有一份原始损坏状态的备份可以回退分析。

我建议备份以下内容：

根文件系统镜像：如果是 LVM 或分区级别的损坏，用 dd 或 ddrescue 备份整个分区。
/boot 分区：内核、initramfs、grub 配置都在这里，升级中断最容易坏的就是它。
关键配置文件：/etc/fstab、/etc/default/grub、/boot/grub2/grub.cfg 等。
升级前的快照：如果系统使用了 LVM 快照或文件系统快照，优先保留快照。

备份命令示例：

# 备份 /boot 分区（假设 /boot 在 /dev/sda1）
dd if=/dev/sda1 of=/tmp/boot_backup_$(date +%Y%m%d).img bs=4M status=progress

# 备份关键配置文件
tar czf /tmp/config_backup_$(date +%Y%m%d).tar.gz /etc/fstab /etc/default/grub /boot/grub2/

# 如果根分区是 LVM，备份 LVM 元数据
vgcfgbackup -f /tmp/lvm_metadata_backup_$(date +%Y%m%d).txt

核心原则： 备份的优先级是 可恢复性 > 完整性。如果磁盘空间有限，优先备份 /boot 分区和配置文件，因为它们体积小、恢复价值高。整个根分区的 dd 镜像虽然完整，但耗时耗空间，可以在条件允许时再做。

2.4 本章知识体系

下面这张图总结了恢复前置准备的三个核心步骤和它们之间的关系：

2.5 避坑指南

最后，分享几个我踩过的坑，希望能帮你省点时间：

不要直接重启：升级中断后，系统可能处于不一致状态。直接重启可能导致文件系统损坏，甚至无法再次引导。先收集信息，再决定下一步。
日志文件可能被截断：如果升级脚本在写入日志时中断，日志文件可能不完整。这时候可以检查 core dump 或 crash dump，它们往往记录了更详细的内存状态。
备份目标盘不要选系统盘：我见过有人把备份直接写到 /tmp 下，结果 /tmp 是 tmpfs，重启就没了。备份一定要放到外部存储或独立分区。
dd 备份前确认目标盘空间：dd 是全盘拷贝，如果目标盘空间不够，它会报错退出，但已经写入的部分可能已经覆盖了重要数据。用 ddrescue 更安全，它支持断点续传。

📚 课程目录

2. 恢复前置准备：确认当前系统状态、收集关键日志、备份当前损坏的镜像

2.1 确认当前系统状态

2.2 收集关键日志

2.3 备份当前损坏的镜像

2.4 本章知识体系

2.5 避坑指南