一次服务器非法重启导致的故障排查记录！

柔情只为你懂 2023-09-26 17:38 6阅读 0赞

前段时间遇到一个服务器问题：**非法重启设备后，服务器进入救援模式，数据盘也不显示挂载是否成功。**

这个问题说来还挺奇葩，今天就来跟大家分享下整个过程以及我的处理方法，避免大家在今后的学习或工作中遇到跟我同样的问题。

#### 一、问题背景 ####

有一天，研发小伙伴跟我反馈有一台服务器连不上，一直卡在如下页面。

![107f8f9e20f5ee88afb8a2d4577a3aac.png][]

该页面是 Xshell 连接某一台服务器时建立的连接，按`Ctrl+Alt+]`键切换到本地 Shell 终端。当我看到卡在该页面时，毫不犹豫地自己也尝试了起来，果然也是连不上。前一天还正常连接，第二天就出问题了？

还好服务器有配置远程管理地址，通过远程控制管理页面的方式启动 iKVM HTML5 和远程管理服务器，这样就能登到这台出故障的设备上查看服务器界面处于一种什么样的状态。

![51605d0734b17886ba7adeafd3f0be7c.png][]

登上这台故障的服务器后，直接重启了服务器，然后 Xshell 再次尝试连接，是可以远程连接的。难道这就是传说中的重启治百病，如此简单粗暴？

![54599207d915c1bb147aab5dd85bb5f2.png][]

当进入系统后，执行简单的命令都提示输入/输出错误。

![520acd38b6db0f85325ca92d31f88b58.png][]

过不久后，直接不建立连接了，彻底挂了。。。

![1620c86702fe827c498926bfab95cd3f.png][]

再通过远程控制管理页面查看服务器当前状态，一看进入到救援模式了。

到该模式下后，

*  输入`journalctl -xb`命令，可查看系统日志；
 *  输入`systemctl reboot`命令，重启系统；
 *  输入`systemctl default`或`^D`命令，再次尝试进入默认模式；
 *  输入 root 用户密码，则可以进入系统。

![c6b0f283e9eef1e8a17ceaab9050c178.png][]

根据日志报错提示：挂载文件系统可以纠正该问题。

![4a45d971fee5e4293669240dda191fd2.png][]

#### 二、解决方案 ####

执行`df -h`命令，用于在 Linux 操作系统下显示文件系统的磁盘使用情况。

使用`-h`选项以`KB`以上的单位来显示，可读性高。

*  第一列：`Filesystem`文件系统的名称；
 *  第二列：`Size`文件系统的容量；
 *  第三列：`Used`已用多少的磁盘空间；
 *  第四列：`Avail`可用多少的磁盘空间；
 *  第五列：`Use%`磁盘使用率；
 *  第六列：`Mounted On`挂载点。

![bd3266412bfbd186e92245a6d20ed892.png][]

根据上图结果来看，没有`/dev/sdb1`文件系统所挂载的`/bigdata`目录磁盘情况。

尝试将`/dev/sdb1`取消挂载，重新挂载，反复报不同的错误。

![8ff40198b105029f5a39186360f19fec.jpeg][]

![66a0308002eca3d0b4fcf0dc2253091f.jpeg][]

![d1aa1a49ec53cdddc56c89ba1bc2322f.jpeg][]

通过 RAID 卡管理界面查看状态也是 Online。

如果重启设备，能看到如下界面，则说明正在初始化设备。

![9b26fe36a7a5e8b79a384b23b9923043.png][]

恰巧，这台故障的服务器由多块硬盘组成的 44T 的一个目录有存放 46% 的数据，在有数据的情况下，如何不格式化磁盘重新挂载呢？

![7c1f47f49ffa133f70895b9ce1e94f59.png][]

**取消挂载**

umount /dev/sdb1

**尝试修复**

若不确定挂载点属于哪种文件类型时，可以执行：`df -Th`命令来判断。

![bd2f0e7964384e50ba02f1a8eeb2bcfd.png][]

如果挂载点为`xfs 文件类型`，可以执行：`xfs_repair -L + 文件系统名称路径`命令进行修复。

如果挂载点为`fsck.ext2/3/4文件类型`，可以执行：`fsck.ext2/3/4文件类型 + 文件系统路径`命令进行修复。

因为我这是`xfs`的文件类型，按`xfs_repair`命令来修复受损的 xfs 文件系统，执行如下命令进行修复`/dev/sdb1`。

xfs_repair -L /dev/sdb1

执行修复是根据磁盘中的数据使用率来决定修复时长的，所以时间会较长，我采用放后台的形式来执行，执行完成后，查看还是否有进程存在，如有则说明未修复完，如没有则说明修复完成，然后再重新挂载。

![c716344b8a3eb0d3e33a0f5b8f51c75b.jpeg][]

mount /dev/sdb1 /bigdata

挂载完毕后，执行`df -h`命令来确定是否挂载成功。

![0fd5f3c7f4be16991be4ebd9e6730ad4.jpeg][]

到此，就恢复挂载完毕了。

上面案例是针对磁盘有数据时且不格式化的情况下恢复并挂载。

那么有小伙伴该问了，无存储数据的情况下，如何挂载磁盘，这里也给大家整理出来一个详细的操作步骤。

**第一步：**

ll /dev/disk/by-path  # 查看需要挂的磁盘名称
    fdisk -l              # 查看磁盘信息
    lsblk                 # lsblk 命令默认情况下将以树状列出所有块设备，包括查看磁盘挂载信息

**第二步：**

parted /dev/sdb mklabel gpt            # 新建 /dev/sdb 的磁盘标签类型为 GPT
    parted /dev/sdb mkpart primary 0 100%  # 将 /dev/sdb 整个空间分给同一个分区
    ignore                                 # 忽略上述执行命令后的告警
    mkfs.xfs -f /dev/sdb                   # 格式化分区

> 注意：格式化分区可能会执行慢些，需耐心等待。

**第三步：**

mkdir /bigdata            # 创建目录，自定义目录名
    mount /dev/sdb /bigdata   # 将 sdb 挂载到 /bigdata 目录下

**第四步：**

blkid   # 查看 sdb 的 UUID 并复制

**第五步：**

vi /etc/fstab    # 参考已挂载的磁盘，将 sdb 的 UUID 和挂载目录关联上，保存后重启设备

> 注意：UUID 一定要写对，否则重启后无法正常进入系统。

**第六步：**

df -h   # 检查是否挂载成功

按照上述操作步骤执行，肯定能操作成功。如果你有更好的解决方案，也欢迎留言分享。

[107f8f9e20f5ee88afb8a2d4577a3aac.png]: https://img-blog.csdnimg.cn/img_convert/107f8f9e20f5ee88afb8a2d4577a3aac.png
[51605d0734b17886ba7adeafd3f0be7c.png]: https://img-blog.csdnimg.cn/img_convert/51605d0734b17886ba7adeafd3f0be7c.png
[54599207d915c1bb147aab5dd85bb5f2.png]: https://img-blog.csdnimg.cn/img_convert/54599207d915c1bb147aab5dd85bb5f2.png
[520acd38b6db0f85325ca92d31f88b58.png]: https://img-blog.csdnimg.cn/img_convert/520acd38b6db0f85325ca92d31f88b58.png
[1620c86702fe827c498926bfab95cd3f.png]: https://img-blog.csdnimg.cn/img_convert/1620c86702fe827c498926bfab95cd3f.png
[c6b0f283e9eef1e8a17ceaab9050c178.png]: https://img-blog.csdnimg.cn/img_convert/c6b0f283e9eef1e8a17ceaab9050c178.png
[4a45d971fee5e4293669240dda191fd2.png]: https://img-blog.csdnimg.cn/img_convert/4a45d971fee5e4293669240dda191fd2.png
[bd3266412bfbd186e92245a6d20ed892.png]: https://img-blog.csdnimg.cn/img_convert/bd3266412bfbd186e92245a6d20ed892.png
[8ff40198b105029f5a39186360f19fec.jpeg]: https://img-blog.csdnimg.cn/img_convert/8ff40198b105029f5a39186360f19fec.jpeg
[66a0308002eca3d0b4fcf0dc2253091f.jpeg]: https://img-blog.csdnimg.cn/img_convert/66a0308002eca3d0b4fcf0dc2253091f.jpeg
[d1aa1a49ec53cdddc56c89ba1bc2322f.jpeg]: https://img-blog.csdnimg.cn/img_convert/d1aa1a49ec53cdddc56c89ba1bc2322f.jpeg
[9b26fe36a7a5e8b79a384b23b9923043.png]: https://img-blog.csdnimg.cn/img_convert/9b26fe36a7a5e8b79a384b23b9923043.png
[7c1f47f49ffa133f70895b9ce1e94f59.png]: https://img-blog.csdnimg.cn/img_convert/7c1f47f49ffa133f70895b9ce1e94f59.png
[bd2f0e7964384e50ba02f1a8eeb2bcfd.png]: https://img-blog.csdnimg.cn/img_convert/bd2f0e7964384e50ba02f1a8eeb2bcfd.png
[c716344b8a3eb0d3e33a0f5b8f51c75b.jpeg]: https://img-blog.csdnimg.cn/img_convert/c716344b8a3eb0d3e33a0f5b8f51c75b.jpeg
[0fd5f3c7f4be16991be4ebd9e6730ad4.jpeg]: https://img-blog.csdnimg.cn/img_convert/0fd5f3c7f4be16991be4ebd9e6730ad4.jpeg