引言

在某天博主新买了某厂家的年卡服务器，并将博客数据迁移到新的服务器中，但是在成功搭建后的几天，可能是 Ubuntu 自动启动盘格式化分区并更改了分区顺序，导致博主 CentOS 7.6 服务器上的 GRUB 启动失败，打开VNC(一种图形化控制台方式，可直接控制服务器“屏幕”)后，出现错误：

GRUB 提示无法找到 normal.mod 文件，系统卡在 grub rescue>，此时操作系统已经不可进入，博主尝试ping服务器IP查看是否可以连接，情况如下：

服务器无法连接，自然博主的站点管理后台也无法进入，而服务器厂家的客服二话不说叫博主重装，由于博主的服务器部署了多个基于宝塔的网站服务，尤其包含重要数据的网站源码和数据库，最新的数据博客未来得及保存，则重装会导致数据丢失且不可逆，因此必须在数据无损的前提下修复系统或导出数据。

本篇文章将系统还原失败场景下，通过 VNC远程救援系统 成功导出数据，读者可以根据本篇文章的经验进行数据恢复操作，将必要的数据备份本地，后续的站点重装恢复则读者根据自身情况自行恢复。

解决方案

临时引导系统（不推荐用于长期）

操作过程

本解决方法是参考网络上的经验贴，链接如下：

https://huaweicloud.csdn.net/63561a6ed3efff3090b5a526.html

根据引言分析， Ubuntu 自动启动盘格式化分区并更改了分区顺序，由于分区表发生变化，/boot 所在分区位置错误，GRUB 无法加载必要模块启动系统，提示无法找到 normal.mod 文件，系统卡在 grub rescue>

解决方法就是查找每个分区，找出Linux操作系统所在的实际分区，然后让改变指定目录到GRUB的实际目录，最后找寻normal.mod 文件，若找到，则可以进入操作系统。

但是在进行实际操作的时候，博主出现以下情况：

博主的操作系统下/boot 文件夹居然没有任何文件，经过分析，原因可能有以下几点：

1. /boot 是单独分区，但当前并未挂载进系统
   • 某些系统在安装时将 /boot 分区独立出来用于提升稳定性。但 grub rescue 中查看的其实是根分区 (hd0,msdos1)，它的 /boot/ 目录只是空壳，并不包含真正的启动文件，因为此时 /boot 分区并未挂载，当然就看不到 grub, grub2, vmlinuz 等重要文件。
2. 分区识别有误，实际进入的并不是有效的 Linux 根分区
   • 有时多分区系统中，可能误进入了 /home 或 /data 等挂载点，尽管这些目录下也存在 /boot/ 文件夹，里面自然没有 bootloader 文件。
3. GRUB 配置损坏或启动文件缺失
   • 如果之前意外删除或格式化过 /boot 分区，或者升级 grub 失败，也可能导致 bootloader 文件彻底丢失。

所以博主使用此方法进行恢复操作系统失败了，但是读者也可以进行此方法的尝试，参照上传的链接教程。

注意事项

在小标题中博主提到，临时引导系统（不推荐用于长期），这是因为在 grub rescue> 中手动输入的启动命令（如 set root=..., insmod normal, normal）不会被永久保存，一旦重启系统就会丢失。若读者成功通过此方法进入操作系统，建议先备份数据，然后修复 GRUB 引导器，在临时系统中输入以下命令：

grub2-install /dev/vda # 安装 GRUB 到主引导记录

grub2-mkconfig -o /boot/grub2/grub.cfg # 重新生成 GRUB 配置文件

注：设备名称 /dev/vda 应根据实际情况调整，如 /dev/sda、/dev/nvme0n1 等。

此时重启系统后也可以正常进入系统了。

但是博主并不推荐这样的做法，因为当出现此问题的时候，可能是由于操作系统版本的潜在危险，后续仍有可能复发，所以建议读者备份数据后重装操作系统，并换新版本。

救援系统导出数据（推荐）

如果 grub rescue 无法启动系统，或系统环境不再稳定，推荐使用云服务提供商的 Rescue模式 进入救援系统，通过 mount 挂载原系统分区后，提取源码与数据库。

首先在服务器操作面板打开，打开救援系统。

读者务必记录密码，救援系统开启后，进入SSH 客户端(本地程序，用于通过 SSH 协议连接远程服务器（即 SSH 服务器）)，本次演示的是FinalShell平台。

在连接面板输入服务器IP、救援系统提供的密码后，可进行连接，由于博主先前已经进行了SSH连接，所以在重新进入面板时，会提示我输入密码。

输入密码后，连接成功。

此时，已经成功通过救援系统连接到主机，然后进行如下操作。

1.查看硬盘分区情况

lsblk # 查看硬盘分区命令

2.挂载原系统磁盘

mkdir /mnt/sysroot # 创建系统目录
mount /dev/vdb1 /mnt/sysroot # 挂载原系统磁盘

/dev/vdb1，是主机挂载磁盘的目录，要根据实际情况改变。

3.查看网站源码与数据库路径

这个根据个人情况而定，在成功进行第二步时，你的系统文件已经挂载到sysroot目录下，此时根据个人网站源码的目录位置进行找寻数据文件(文件要自己找)，比如我是宝塔平台，我的网站源码和数据文件找寻命令如下。

ls /mnt/sysroot/www/wwwroot # 源码目录
ls /mnt/sysroot/www/server/data # 数据库目录

上述3点的操作图如下。

4.分别打包源码与数据库

在找到个人网站的源码和数据文件后，需要进行打包并备份到本地。

# 打包网站源码
tar -zcvf /root/wwwroot_backup.tar.gz -C /mnt/sysroot/www wwwroot

# 打包数据库data文件
tar -zcvf /root/mysql_data_backup.tar.gz -C /mnt/sysroot/www server/data

博主是打包压缩到到root文件下了，然后下载到本地即可。

此时则完成了网站源码与数据文件的备份操作，若有其它备份文件，则自行找寻与压缩下载。

注：博主下载的data为物理文件，并非.sql文件，这是由于救援系统并非是实际的操作系统。

尾声

在本次博客中，深入记录了 CentOS 服务器突发宕机后，通过 VNC 登录控制台所遇到的 GRUB 启动失败问题，并围绕 grub rescue> 模式下 /boot 目录为空的现象展开分析。通过对各个分区的排查，发现虽然某分区包含操作系统文件结构，但其 /boot 目录实际上并无任何启动模块，推测原因为系统采用独立 /boot 分区但当前未被正确挂载，或相关文件已在此前损坏或丢失，导致临时修复 normal.mod 失败。最终借助 BT 面板救援系统，通过手动挂载分区、导出网站源码与数据库，实现了数据完整恢复。

后续读者的个人网站源码和数据恢复，由于不同网站存在差异性较大，所以请自行解决。