一次因NAS存储故障引起的Linux系统恢复案例

一、故障现象描述

NAS操作系统内核为Linux，自带的存储有16块硬盘，总共分两组，每组做了RAID5，Linux操作系统无法正常启动，在服务启动到cups那里就停止了，按键ctrl+c强制断开也没有响应，查看硬盘状态，都是正常的，没有报警或者警告现象。

二、问题判断思路

通过上面这些现象，首先判断NAS硬件应该没问题，NAS存储盘也应该正常，现在Linux无法启动，应该是Linux系统本身存在问题，因此，首先从Linux系统入手进行排查。

三、问题处理过程

1、第一次处理过程

NAS系统本身就是一个Linux内核装载了一个文件系统管理软件，管理软件可以对系统磁盘、系统服务、文件系统等进行管理和操作，正常情况下，基于Linux内核的NAS系统应该启动到init3或者init5模式下，由于NAS仅用了Linux一个内核模块和几个简单服务，所以判断NAS下的Linux系统肯定是启动到init 3模式下，那么现在无法启动到多用户字符界面下，何不让Linux直接进入单用户（init 1）模式下呢，因为单用户模式下仅仅启用系统所必须的几个服务，而cpus服务是应用程序级别的，肯定不会在“init 1”模式下启动，这样就避开了cups无法启动的问题，所以，下面的工作就是要进入Linux的单用户模式下。

很多的Linux发行版本都可以在启动的引导界面通过相关的设置进入单用户模式下，通过查看NAS的启动过程，基本判断这个Linux系统与RHEL/Centos发行版极为类似，因此，就通过RHEL/Centos进入单用户模式的方法试一试。

RHEL/Centos进入单用户模式很简单，就是在系统启动到引导欢迎界面下，按键e，然后编辑正确的内核引导选项，在最后面加上“single”选项，最后直接按键“b“即可进入单用户了。

接下来，重新启动NAS，然后硬件自检，接着开始启动Linux，一直在等待这个NAS的启动欢迎界面，但是欢迎界面一直没出来，就直接进入内核镜像，加载内核阶段了，没有内核引导界面，如何进入单用户啊，经过简单思考，还是决定在硬件检测完毕后直接按键盘”e“键，奇迹出现了，还真的可以，NAS进入到了内核引导界面，通过简单观察，发行第二个正是要引导的内核选项，于是移动键盘上下键，选择这个内核，然后在按键”e“，进入内核引导编辑界面了，在这行的最后面，输入“single”，然后按回车键，返回上个界面，接着按键“b”开始进行单用户引导，经过一分钟的时间，系统如愿以偿的进入了单用户下的shell命令行。

进入单用户模式后，能做的事情就很多了，首先要做的就是将cups服务在多用户模式下自启动关闭，执行命令如下：

chkconfig --levle 35 cups off

执行成功后，重启系统进入多用户模式下，看看系统是否能正常启动。

2、第二次处理过程

将cups服务开机自启动关闭后，重启NAS，发现问题依旧，NAS还是启动到cups服务那里停止了，难道上面的命令没有执行成功吗？明明已经禁止了cups服务启动了，怎么还是启动了呢？于是，继续重启NAS，再次进入单用户模式下，看看问题究竟出在哪里了。

进入单用户后，再次执行chkconfig 命令，依旧可以成功，难道是cups服务有问题，先看看配置文件，执行如下命令：

vi /etc/cups/cupsd.conf

在这里发现了一个问题，vi打开cupsd.conf时，提示“write file in swap”，文件明明真实存在，怎么说在虚拟内存中呢，经过思考，只有一种可能，NAS设备的Linux系统分区应该没有正确挂载，导致在进入单用户的时候，所有文件都存储在了虚拟内存中，要验证非常简单，执行“df”命令查看即可，如下图所示：

从这里可以看出，Linux的系统分区并未挂载，通过"fdisk -l"检查下磁盘分区状态，输出如下图所示：

通过输出可知，NAS的系统盘是/dev/sda，仅划分了/dev/sda1和/dev/sda2两个系统分区，而数据磁盘是经过做RAID5完成的，在系统上的设备标识分别是/dev/sdb1和/dev/sdc1，由于单用户默认没有挂载任何NAS磁盘，这里尝试手动挂载NAS的系统盘，执行如下命令：

 [root@NASserver ~]#mount /dev/sda2 /mnt

[root@NASserver ~]#mount /dev/sda1 /opt

这里的/mnt、/opt是随意挂载的目录，也可以挂载到其他空目录下，挂载完成，分别进入这连个目录看看内容有什么，如下图所示：

通过这两个内容的查看，初步判断，/dev/sda2分区应该是Linux的根分区，而/dev/sda1应该是/boot分区。现在分区已经挂载上去了，再次执行df命令看看挂载情况，如下图所示：

到这里为止，发现问题了。/dev/sda2磁盘分区已经没有可用的磁盘空间了，而这个分区刚好是NAS系统的根分区，根分区没有空间了，那么系统启动肯定就出问题了。

下面再把思路转到前面介绍的案例中，由于系统cups服务在启动的时候会写启动日志到根分区，而根分区因为没有空间了，所以也就无法写日志了，由此导致的结果就是cups服务无法启动，这就解释了此案例中NAS系统每次启动到cups服务就停止的原因。

四解决问题

由于NAS系统只有根分区和/boot分区，所以系统产生的相关日志都会存储在根分区中，现在根分区满了，首先可以清理的就是/var目录下的系统相关日志文件，通常可以清理的目录有/var/log，执行如下命令查看/var/log日志目录占据磁盘空间大小：

[root@NASserver ~]#  du -sh /var/log

50.1G    /var/log

通过命令输出发现/var/log目录占据了根分区仅70%的空间，清理这个目录下的日志文件即可释放大部分根分区空间，清理完毕，重启NAS系统，发现系统cups服务能正常启动了，NAS服务也启动正常了。

以上就是一次因NAS存储故障引起的Linux系统恢复案例的全部过程，在此感谢本文原创出处 “技术成就梦想” 博客，谢绝转载！谢谢阅读，希望能帮到大家，请继续关注靠谱客，我们会努力分享更多优秀的文章。

最后

以上就是靓丽冬天为你收集整理的一次因NAS存储故障引起的Linux系统恢复案例的全部内容，希望文章能够帮你解决一次因NAS存储故障引起的Linux系统恢复案例所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。