前段时间遇到一个服务器问题:非法重启设备后,服务器进入救援模式,数据盘也不显示挂载是否成功。
说来这个问题,我觉得还挺奇葩。今天就来跟大家分享下整个过程以及我的处理方法。避免大家在今后的学习或工作中遇到跟我同样的问题。
一、问题背景
有一天,研发小伙伴跟我反馈有一台服务器连不上,一直卡在如下页面。
该页面是 Xshell 连接某一台服务器时,建立的连接,按Ctrl+Alt+]键切换到本地 Shell 终端。当我看到卡在该页面时,毫无犹豫的自己也尝试了起来,果然也是连不上。前一天还正常连接,第二天就出问题了?
还好服务器有配置远程管理地址,通过远程控制管理页面的方式启动 iKVM HTML5 和远程管理服务器,这样就能登到这台出故障的设备上查看服务器界面处于一种什么样的状态。
登到这台故障的服务器后,直接重启了服务器,然后 Xshell 再次尝试连接,是可以远程连接的。难道这就是传说中的重启治百病,如此简单粗暴?
当进入系统后,执行简单的命令都提示输入/输出错误。
过不久后,直接不建立连接了,彻底挂了。。。
再通过远程控制管理页面查看服务器当前状态,一看进入到救援模式了。
到该模式下后
- 输入journalctl -xb命令,可查看系统日志
- 输入systemctl reboot命令,重启系统
- 输入systemctl default或^D命令,再次尝试进入默认模式
- 输入 root 用户密码,则可以进入系统
根据日志报错提示:挂载文件系统可以纠正该问题。
二、解决方案
执行df -h命令,用于在 Linux 操作系统下显示文件系统的磁盘使用情况。
使用-h选项以KB以上的单位来显示,可读性高。
- 第一列:Filesystem文件系统的名称
- 第二列:Size文件系统的容量
- 第三列:Used已用多少的磁盘空间
- 第四列:Avail可用多少的磁盘空间
- 第五列:Use%磁盘使用率
- 第六列:Mounted On挂载点
根据上图结果来看,没有/dev/sdb1文件系统所挂载的/bigdata目录磁盘情况。
尝试将/dev/sdb1取消挂载,重新挂载,反复报不同的错误。
通过 RAID 卡管理界面查看状态也是 Online。
当如果重启设备,能看到如下界面,则说明正在初始化设备。
恰巧,这台故障的服务器有多块硬盘组成的 44T 的一个目录有存放 46% 的数据,在有数据的情况下,如何不格式化磁盘重新挂载呢?
取消挂载
尝试修复
若不确定挂载点属于哪种文件类型时,可以执行:df -Th命令来判断。
如果挂载点为xfs 文件类型,可以执行:xfs_repair -L + 文件系统名称路径命令进行修复。
如果挂载点为fsck.ext2/3/4文件类型,可以执行:fsck.ext2/3/4文件类型 + 文件系统路径命令进行修复。
因为我这是xfs的文件类型,按xfs_repair命令来修复受损的 xfs 文件系统,执行如下命令进行修复/dev/sdb1。
执行修复是根据磁盘中的数据使用率来决定修复时长的,所以时间会较长,我采用放后台的形式执行的,执行完成后,查看还是否有进程存在,如有则说明未修复完,如没有则说明修复完成,然后再重新挂载。
挂载完毕后,执行df -h命令来确定是否挂载成功。
到此,就恢复挂载完毕了。
上面案例是针对磁盘有数据时且不格式化的情况下恢复并挂载。
那么有小伙伴该问了,无存储数据的情况下,如何挂载磁盘,我这里也给大家整理出来一个详细的操作步骤:
第一步:
第二步:
注意:格式化分区可能会执行慢些,需耐心等待。
第三步:
第四步:
第五步:
注意:UUID 一定要写对,否则重启后无法正常进入系统。
第六步:
按照上述操作步骤执行,肯定能操作成功。如果你有更好的解决方案,也欢迎大家留言分享。
参考文献
xfs_repair命令详解 https://bbs.qunyingkeji.com/2052/