AIO 翻车自救手册
翻车前的准备工作
AIO 翻车往往不是慢慢发生的,而是某一时刻全家断网、NAS 不见、影音不开。这时候最怕两件事:一没有带外管理手段,二不知道改了什么导致。准备工作其实很短:给宿主留一根不依赖虚拟路由的网络通道。最简单的办法是宿主管理 IP 与虚拟路由的子网分开,或者干脆物理上用另一块网卡接交换机固定 IP,即使路由虚拟机死掉,内网中任意电脑也能直连宿主敲命令。
第二个准备是保持文字记录:每次改动前在本地记一句话——改了哪个文件、加了什么参数、回退方法是删掉哪行。有了这个,自救时间从一小时缩到五分钟。第三个准备是常备一个最小系统启动盘和一个移动硬盘里的宿主配置备份,核心三件套配齐,心就不慌。这些准备工作最好在系统一切正常时完成,翻车之后再想做就难了。

路由虚拟机罢工
症状是内网设备拿不到 IP、网页打不开,但宿主还能登录。第一步先分清是路由死了还是链路死了:光猫直接接电脑拨号试一下,或者手机连光猫自带 WiFi 看能不能上网。如果外网正常,问题在路由虚拟机。进宿主把路由虚拟机强制停止再开机,多数情况能恢复;不行就回滚到最近一次快照,快照是翻车现场最锋利的工具。
如果是改配置改挂的,进路由系统把最近改动还原。这里有个高频陷阱:路由虚拟机 WAN 网卡直通后,某次宿主升级触发了 IOMMU 分组变化,开机时设备找不到了。排查方法是检查内核参数是否还在(cat /proc/cmdline),以及虚拟机硬件列表里 PCI 设备是否还选中着目标。还有一类是 DHCP 地址池耗尽或地址冲突,表现为部分设备断网、重启路由暂时有效,治本要查是不是存在两个 DHCP 服务器——常见于旁路由没关 DHCP、或者 AP 自带 DHCP 没关。
| 症状 | 大概率原因 | 自救顺序 |
|---|---|---|
| 全屋断网 | 路由虚拟机崩溃 | 重启路由,回滚快照 |
| 宿主也失联 | 管理网络与路由同段 | 插显示器或走带外口 |
| 存储共享不通 | 服务或网络问题 | 先查服务再查磁盘 |
| 虚拟机转圈不开机 | 直通设备丢失 | 查分组与 PCI 配置 |
| 备份任务报错 | 备份盘满或路径失效 | 清空间再补跑一次 |
存储虚拟机起不来
NAS 虚拟机开机失败、反复重启,先看宿主的日志与存储状态。最常见的原因是直通磁盘的识别问题:某次插拔硬盘后盘符漂移,配置里认死编号的设备就找不到了。所以涉及硬盘直通的配置,一定用 /dev/disk/by-id 这类稳定标识而不是动态盘符。第二种原因是文件系统损伤:强行断电后 ZFS 池进入挂起或降级状态,进虚拟机用 zpool status 查看错误,按提示 zpool clear 或者先导出再导入,多数能救回,ZFS 的自愈能力远好于无校验的文件系统。
碰到存储假死(数据盘还在但共享不通),先别急着重启。SMB 与 NFS 服务本身挂掉的概率远大于磁盘损坏,重新启动对应服务即可;磁盘灯狂闪不熄才是真正的硬件警告,这时候要准备换盘与数据迁移。记得一个铁律:只要怀疑硬盘有问题,先 rsync 抢救数据到别处,而不是跑各种检测工具反复读盘——每次全盘扫描都是对濒死硬盘的酷刑。
宿主起不来
最严重的情形是宿主自身无法启动,黑屏或者卡在引导。这时候心态一定要稳,所有虚拟机数据都在硬盘上,不会因为系统起不来就消失。先用启动盘引导进救援模式,检查 /etc/default/grub 与 /etc/kernel/cmdline 有没有被改错(最常见的是改 IOMMU 参数时引号或参数名写错),改回来 update-grub 试试。如果是 systemd-boot 环境,proxmox-boot-tool refresh 修复引导项。
ZFS 根的系统可以 zpool import rpool 看池状态,多数情况下池完好,只是引导条目丢了。内存条松动与电源供电不足也会表现为开机无显示,硬件角度别忽视。救回后第一件事是把 grub 与 cmdline 的修改做最小化验证:一次只改一个参数,每次都能正常开机再继续,别图省事一次改三处。

服务层面的连环崩
有时候宿主与虚拟机都活着,但某个应用疯狂报错。典型是 Docker 容器反复重启,原因经常是数据目录权限不对或者磁盘满了——一条 df -h 就能看出来。再比如智能家居网关掉线,可能是上游 DNS 服务(比如 AdGuard Home)挂了导致设备解析不了域名,问题在 DNS 而不在网关。连环崩的排查技巧是顺藤摸瓜:从报错的服务一路往上游问,DNS 通吗、存储通吗、网关通吗,链条上第一个出问题的通常就是根因。
远程登录卡死轮不到 SSH 时,PVE 网页控制台就是最后的通道,所以平时务必保证 8006 端口的管理网络可达,把宿主管理地址记在路由器静态绑定里,纠纷时刻少一次回忆。关于这部分的排错工具与日志查看技巧,可以参考 SSH 远程登录与加固 里的常用命令速查。
自救工具箱与复盘
翻车救回来之后值得花十分钟做一次复盘,把事故记到一个简单的文档里:什么时间、什么改动导致、怎么发现的、恢复用了多久、以后怎么避免。这份事故文档的价值超乎想象——同样的配置错误两年后你会再犯一次,除非文档提醒了你。复盘不用写漂亮,四五行流水账即可,关键是时间和原因两列。
工具箱方面,常备这些东西在物理上触手可及:一个装了 PVE 安装镜像的 U 盘、一根 HDMI 线加键盘、一张打印好的网络拓扑与 IP 表(贴在机箱内侧)、以及一份数据线。全部成本不到五十块钱,但在断网后焦急的时刻能走完全部自救流程而不是干瞪眼。U 盘里再放一份宿主配置的最近备份就更完美了。
还有一个心理层面的准备:翻车时刻最好的动作是先深呼吸三分钟再敲命令。AIO 玩家翻车时的二次破坏(紧张中执行了 rm 而不是 cp、顺手把另一台虚拟机也重启了)远多于事故本身造成的损失。稳定情绪 + 文档化习惯 + 完备备份,三者齐备的家庭网络其实很难真的翻车。
补一份真实事故的统计感观:在社区案例里,AIO 事故的三大根因分别是“升级没做快照”“网络改动忘了备份”“存储满了还在写入”,加起来占七成以上。对应到本手册的动作都很轻量:升级前 qm snapshot 一行命令、改动前 cp 一份配置文件、监控加一条空间告警。知道多数人栽在哪里,自己躲开就容易多了。

日常防翻车的习惯清单
把自救能力变成日常习惯,比翻车后背口诀管用。五条习惯按重要性排序:第一,任何改动前先备份或快照,哪怕只是改一个配置项;第二,带外通道永远可用(显示器与键盘放机器旁、管理网段与业务网段分离);第三,维护日志随手记两行;第四,重要操作一次只动一个变量,改完验证再动下一个;第五,永远不半夜做大操作,深夜判断力差一档是生理规律。
清单贴在机箱内侧更有用:/home 与 /etc 的备份位置、各虚拟机的自启顺序、紧急联系方式、运营商报障需要的账号信息。一张 A4 纸的信息密度足够覆盖自救全部场景。很多老玩家把这张纸视为家庭运维的终极配置,评比 AIO 水平不看面板多炫,就看这张纸。
自救能力的上限
诚实面对一件事:自救能力有上限,电力、硬件、运营商级别的故障不是配置能救的。UPS 保住半小时优雅关机、冷备硬盘保住数据、一张写清楚的清单保住恢复顺序,这三件做到了,其余的交给时间。心态上接受“全家断网一晚”的可能,反而能减少紧张导致的二次事故。
补一套“分级停机”的操作顺序,翻车时按这个顺序评估损失而不是乱关:先停应用与工具机(它们停了家人最多觉得安静),再停存储虚拟机(先等任务结束,避免写盘中断),最后才动路由(动它等于全屋断电)。恢复顺序正好反着来。这个顺序写在应急清单上,停电与火灾演习般的时刻就能有条不紊。
一句总结
AIO 翻车自救的本质是把“怕”变成“有准备”:怕断网就准备带外通道,怕改错就准备快照与日志,怕数据丢就准备三层备份。所有准备工作加起来不超过一台机器成本的十分之一,但它们让整个家庭网络从“脆弱的单点”变成“可以放心折腾的平台”。翻过几次车、救回来几次之后,你会发现自救能力本身就是 AIO 玩家最值钱的技能。
附一段给新手的话:第一次翻车时心跳加速是正常的,全身冒汗也是正常的。那些从容不迫的论坛大佬不是天赋异禀,只是翻得多了。给自己一次完整自救的机会(哪怕最后只回滚了快照),第二次就会平静很多。翻车是这门手艺的必修课,不是失败。
自救完成后还有一步别忘:把这次事故补进速查手册(见后文故障速查一章)。个人的经验只有写下来才会变成系统的资产,下次半夜遇到同样症状,你或未来的你打开手册就能按图索骥。这就是为什么有人折腾三年越来越从容,有人折腾十年还是每次都从头排查。
延伸阅读
- SSH 远程登录与加固:排错必备的命令行技能与常用日志查看方法。
- 计算机网络入门:理解 DNS、DHCP 与 ARP 的排查链条,定位连环崩更高效。
