搬瓦工系统无法启动怎么办？KiwiVM 控制台、救援与数据恢复
VPS 重启后 SSH 一直超时，先不要点“重装系统”。Linux 可能已经启动，只是网络、防火墙或 SSH 服务出了问题；也可能停在 emergency mode，等待处理挂载错误。这两类故障的恢复方式完全不同。
下面按“保存现场 → 确认状态 → 取回数据 → 针对修复”的顺序处理。涉及磁盘时，所有设备名都要用实际输出核对；不提供一键格式化、自动 fsck -y 或不分 BIOS/UEFI 的引导修复命令。
一、先用控制台看最后停在哪里
进入 KiwiVM 控制面板，区分 Running、Stopped 和明确的暂停提示。Stopped 只表示当前未运行，不能单独证明因滥用被停机。若有暂停说明，应先处理说明对应的原因。
打开当前面板提供的控制台，保存最后报错画面和发生时间。若能登录系统，先执行：
systemctl --failed
sudo journalctl -b -p err --no-pager -n 150
ip -br address
ip route
sudo ss -lntp
系统已启动而 SSH 不通，应转到 搬瓦工 SSH 连接不上怎么办？完整排查方法，不要为了网络问题修复文件系统。若卡在磁盘挂载、initramfs 或 kernel panic，再考虑救援。
二、什么时候使用 Live ISO
KiwiVM 的历史救援流程包括挂载 Live ISO、停止后重新启动、进入试用系统并访问原磁盘。实际可用 ISO、控制台名称和启动方式以当前面板为准；不要照着旧资料安装已经停止维护的系统。选择有 Live/救援环境的镜像，而不是自动安装到磁盘。[1]
停止虚拟机会中断业务；若还能从系统内正常关机，优先正常关机。已经完全无响应时才评估强制停止。重启和重装都会改变现场，重要数据优先保留独立副本。
进入 Live 系统后，选择试用或救援选项，不点击安装、初始化磁盘或自动分区。
三、识别原磁盘，避免挂错设备
lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINTS
sudo blkid
findmnt
设备名可能是 /dev/vda、/dev/sda 或其他名称，根文件系统也可能位于 LVM 逻辑卷中。ISO 的设备不是原系统盘，Live 系统的 / 也不是原系统的 /。
确认是 ext4、且没有被自动挂载后，可先建立只读查看点：
sudo mkdir -p /mnt/source
# /dev/REPLACE_ROOT 是占位符，必须替换为确认后的 ext4 根分区
sudo mount -t ext4 -o ro,noload /dev/REPLACE_ROOT /mnt/source
noload 用于避免回放 ext4 日志；损坏或未正常卸载的文件系统可能因此呈现不一致视图，不能把这份视图当作已经完成修复。其他文件系统不使用此命令。[2] 数据极其重要、存在底层读写错误或需要保留证据时，应先做块级副本并在副本上处理，必要时请求专业恢复支持。
先确认 /mnt/source/etc、站点目录和用户目录确实属于原系统。不要把恢复出来的文件保存回故障盘，也不要把 Live 环境的临时内存目录当成持久备份。
四、先保存文件，再谈数据库恢复
网站文件、配置和附件可复制到另一台受控主机或独立存储。数据库目录的文件级副本不等于可直接导入的逻辑备份，能否恢复取决于数据库类型、版本、日志和关闭状态。优先使用最近已验证的逻辑备份；不要在受损源盘上反复尝试启动数据库写入。
如果能创建并下载完整快照，可把它作为额外的回退或取数途径，但要确认操作能力及存储空间。参考 搬瓦工快照与自动备份教程。任何修复前先保存唯一可用副本，避免修复失败后连原始状态也丢失。
五、按错误修复，不套万能命令
fstab 引用了不存在的 UUID
先查看原系统的 etc/fstab，与 blkid 对照。修改前备份这个文件，只调整确认错误的条目。非关键外部挂载是否使用 nofail 要按业务要求决定；根文件系统或必要数据盘不能为了让开机通过就随意跳过。
文件系统需要检查
先卸载所有访问该文件系统的挂载点，再进行对应工具的离线检查。对于确认是 ext2/3/4 的设备，可先做不写入的检查：
sudo umount /mnt/source
# 确认设备没有在其他路径被挂载后再执行
sudo e2fsck -f -n /dev/REPLACE_ROOT
即使使用 -n，在挂载中的文件系统上检查也可能得到不可靠结果。真正写入修复前必须有备份，并理解工具提出的修改。XFS、Btrfs 和 LVM 的处理流程不同，不能使用 e2fsck 代替。[3]
更新后无法启动
若引导菜单可选择之前已安装的内核，可先用它判断新内核是否有关。不要在生产故障期间随机安装所谓优化内核。修改 GRUB、initramfs 或 bootloader 之前，先确认根分区、单独 /boot、EFI 分区与启动模式；不清楚布局时提交工单并附设备信息。
空间满或配置服务失败
空间问题先定向清理可重建内容；不能删除数据库文件。服务配置错误先查看失败单元和日志，而不是在 Live 系统里批量禁用所有服务。可恢复时尽量保持变更最小，便于知道哪一步产生了作用。
六、退出救援与启动验证
检查没有遗留后台复制任务，按顺序卸载挂载点，取消 ISO 并从系统磁盘启动。若进过 chroot，还要正确退出并卸载相关绑定目录；不能在尚有写入时直接断电。
启动后检查 systemctl --failed、当前启动日志、文件系统挂载、磁盘空间与网络，再验证数据库、网站和最近业务记录。数据库恢复成功还要看应用是否能写入，不只检查端口是否监听。
七、什么时候应该重建
确认被入侵、系统来源不可控，或修复风险已经高于重新部署时，可以在新实例重建，再恢复干净的业务数据。不要把后门和异常自启动项随快照一起带回去。重装前参考 搬瓦工重装系统教程：Ubuntu / Debian 怎么选，并重新检查密码、密钥、第三方 Token 和访问来源。
常见问题
Live ISO 可以直接安装来修复吗？
安装可能覆盖磁盘，不等同于救援。先进入试用或救援环境，确认原盘和数据。
fsck 会不会丢文件？
写入修复可能调整元数据和损坏对象。先保留副本，再选择对应文件系统工具，不自动接受所有修改。
控制台能用就不需要备份了吗？
控制台只是访问方式，不提供数据副本。磁盘损坏时，即使能看到目录，也不代表数据可完整恢复。
相关阅读
参考资料
