大家好，我叫杰哥。
前段时间遇到一个服务器问题：非法重启设备后，服务器进入救援模式，数据盘没有显示是否挂载成功。
一、问题背景
有一天，一位研发伙伴向我反映，有一台服务器无法连接，卡在以下页面。
该页面是Xshell连接某台服务器时建立的连接。按Ctrl+Alt+] 键切换到本地Shell 终端。当我看到卡在这个页面时，我毫不犹豫地自己尝试了一下，果然无法连接。一天连接正常，第二天就出问题了？
幸运的是，服务器配置了远程管理地址。您可以通过管理页面的远程控制启动iKVM HTML5和远程管理服务器，以便您可以登录故障设备并检查服务器界面的状态。
登录失败的服务器后，我直接重新启动服务器，然后尝试使用Xshell再次连接。可以远程连接。难道这就是传说中的包治百病的重启，就这么简单粗暴吗？
进入系统后，执行简单命令时提示输入输出错误。
过了一会儿，连接就不再建立了，完全挂断了。
然后通过远程控制管理页面查看服务器当前状态，看到已经进入救援模式。
进入该模式后
输入journalctl -xb命令查看系统日志。输入systemctl 重新启动命令。要重新启动系统，请输入systemctl default 或^D 命令。尝试再次进入默认模式，输入root用户密码进入系统。
根据日志中的错误信息：挂载文件系统即可解决问题。
二、解决方案
Linux操作系统下执行df -h命令可以显示文件系统的磁盘使用情况。
使用-h选项以KB或以上为单位显示，可读性更强。
第一列：Filesystem 文件系统的名称第二列：Size 文件系统的容量第三列：Use 已使用了多少磁盘空间第四列：Avail 可用的磁盘空间有多少第五列：使用%磁盘使用率第六列列：Mounted On 挂载点
根据上图结果，/dev/sdb1文件系统挂载的/bigdata目录磁盘不存在。
尝试卸载/dev/sdb1并重新挂载，但反复报不同的错误。
通过RAID卡管理界面查看状态也是Online。
重启设备后看到如下界面，说明设备正在初始化。
巧合的是，这台故障服务器有一个由多个硬盘组成的44T目录，存储了46%的数据。如果有数据，如何在不格式化的情况下重新挂载磁盘呢？
取消挂载
umount /dev/sdb1
尝试修复
如果不确定挂载点属于哪种文件类型，可以执行df -Th 命令来确定。
如果挂载点是xfs文件类型，可以执行xfs_repair -L + 文件系统名称路径命令进行修复。
如果挂载点是fsck.ext2/3/4文件类型，可以执行fsck.ext2/3/4文件类型+文件系统路径命令进行修复。
因为这是xfs的文件类型，所以按xfs_repair命令修复损坏的xfs文件系统。执行以下命令修复/dev/sdb1。
xfs_repairL/dev/sdb1的修复时间是根据磁盘中的数据使用情况来确定的，所以会需要很长的时间。我在后台执行了它。执行完成后，检查是否还有进程。如果是这样，则说明修复尚未完成。如果没有，说明修复完成，然后重新挂载。
mount/dev/sdb1/bigdata挂载后，执行df -h命令判断是否挂载成功。
至此，恢复和挂载就完成了。
以上情况是针对磁盘有数据且未格式化时的恢复和挂载。
那么就有朋友要问了，没有存储数据的情况下如何挂载磁盘呢？我这里也给大家详细的操作步骤：
第一步：
ll /dev/disk/bypath # 查看需要挂载的磁盘名称
fdiskl # 查看磁盘信息
lsblk # lsblk命令默认会以树形视图列出所有块设备，包括查看磁盘挂载信息。步骤2：
parted/dev/sdb mklabel gpt # 创建/dev/sdb的新磁盘标签类型为GPT
parted/dev/sdb mkpartprimary0100%#将/dev/sdb整个空间分配到同一个分区
ignore # 执行上述命令后忽略警告
mkfs.xfsf/dev/sdb # 格式化分区
注意：格式化分区可能会比较慢，请耐心等待。
第三步：
mkdir/bigdata #创建目录并自定义目录名称
mount/dev/sdb/bigdata # 将sdb 挂载到/bigdata 目录。第4步：
第5步：
vi /etc/fstab # 引用挂载的磁盘，将sdb的UUID与挂载目录关联起来，保存并重启设备
注意：UUID一定要写正确，否则重启后将无法正常进入系统。
第6步：
dfh # 检查是否挂载成功
参考文献
xfs_repair 命令详解https://bbs.qunyingkeji.com/2052/
一次服务器非法重启后导致的故障排查记录-没网了怎么排查故障和的问题分享结束啦，以上的文章解决了您的问题吗？欢迎您下次再来哦！
本文采摘于网络，不代表本站立场，转载联系作者并注明出处：https://www.iotsj.com//kuaixun/7552.html
用户评论
哎哟喂，服务器重启售后真的要好好检查一遍啊，不然这样麻烦。
有13位网友表示赞同！
说起来网络不通还是挺常见的问题，看来还得多学习点知识才行。
有17位网友表示赞同！
这篇文章能记录下详细的排查过程，对之后遇到相同问题的人很有帮助。
有8位网友表示赞同！
服务器重启后没网？那肯定得先检查一下网络线有没有松了。
有11位网友表示赞同！
有时候连简单的问题都能折腾人半天，这篇记录挺有亲切感。
有12位网友表示赞同！
希望以后不会再遇到这种问题，感觉要整理服务器日志的习惯。
有18位网友表示赞同！
看了下这篇文章，好像自己还是缺乏一些系统管理的知识啊。
有8位网友表示赞同！
分享到博客上吧，让更多人知道如何解决这个问题。
有9位网友表示赞同！
服务器重启后没网，可能是路由器的问题吧？
有13位网友表示赞同！
记录这种经验也很重要，以后遇到类似问题可以参考一下。
有16位网友表示赞同！
没网的时候真叫人着急！这篇文章内容很详细，有学习价值。
有11位网友表示赞同！
看来还要好好学习学习网络基础知识呢。
有8位网友表示赞同！
服务器管理确实是一门技术活，需要不断积累经验。
有20位网友表示赞同！
这种排查记录可以作为学习资料分享给新手小白们。
有10位网友表示赞同！
希望作者以后还会多写一些这样的文章！
有14位网友表示赞同！
服务器重启后问题总是让人抓狂，这篇记录帮了不少忙。
有17位网友表示赞同！
这篇文章让我明白，记录和分析是解决问题的关键步骤。
有18位网友表示赞同！
没网真是太蛋疼了，还好有人分享了解决方案！
有18位网友表示赞同！
总结经验教训很重要，这样下次遇到问题就能更迅速解决。
有20位网友表示赞同！
服务器管理是一个不断学习的过程，这篇文章对我很有启发。
有6位网友表示赞同！