因NAS存儲故障引起的Linux系統恢復的過程分析

這篇文章主要介紹“因NAS存儲故障引起的Linux系統恢復的過程分析”，在日常操作中，相信很多人在因NAS存儲故障引起的Linux系統恢復的過程分析問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”因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系統恢復的過程分析”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！