生產事故：誤刪/lib64，移走/lib64目錄

事故背景：

有一臺機器裝不上nagios監控，yum install openssl報一個關于“libkrb5.so.3”沖突的錯誤。

解決過程：

1./lib64事故

關于“libkrb5.so.3”沖突的錯誤，查了一些文章沒有解決，就想著把libkrb5卸掉，rpm -e libkrb5.rpm，卸載有關聯沖突，然后就rpm -e libkrb5.rpm --nodeps（事實證明，如果不清楚軟件的依賴，最好不要“--nodeps”），一卸載就發現問題了，發現yum命令用不了了，提示缺少“libkrb5.so.3”，然后我就從別的機器上拷貝了一個libkrb5.so.3到這臺機器上，然后yum繼續提示少別的文件，經驗告訴我，這可能還缺少別的很多庫文件，由于是生產的機器，我不想花太多時間整，所以就想著從別的機器上拷貝/lib64到這臺機器，想著想著，手就不由自主的敲了個“mv /lib64 /tmp”，敲完我就后悔了，趕緊“ls”，發現用不了了，然后發現只有cd命令能用，其他的都用不了，這個時間點大概是15:00，說實話，有點慌，因為生產上沒有遇到過這種事，在虛擬機上試過“rm -rf /”能刪，但是也沒恢復過。

2.模擬并處理/lib64事故

想了一分鐘，決定在虛擬機上模擬這個事故，打開虛擬機，然后mv /lib64 /tmp，重啟，進不去系統，一直卡在開機界面。然后就開始搜索“誤刪/lib64”的相關文章，幾乎沒找到有用的，可能是因為這個事故確實比較少，生產中沒人會這么做，實驗的話可能也不會做這個。沒搜到“誤刪/lib64”的文章，但是有個文章的“linux修復模式”提醒了我，心想：我可以先進了系統，然后把/tmp目錄下的lib64拷貝回/根目錄，這樣不就解決問題了嗎。

然后我就在虛擬機上試驗，進入linux修復模式下后，發現/tmp目錄下的文件被刪了，然后就想到/tmp目錄下的文件是不是重啟后自動刪除了，然后我就把光盤鏡像系統里的/lib64拷貝到崩潰的系統根目錄下，重啟系統，依舊不行，這可能是依舊缺少什么庫文件導致的系統起不來。

很著急很著急，因為現在我誤認為/tmp/lib64這個目錄在重啟系統后就被刪除了，而且鏡像里的/lib64拷貝到崩潰系統里也是不起作用的，沒辦法了，我只能想著把系統里的東西導出來，這是一臺發布機器，深圳那邊的同事專門用來發布代碼的，恰巧當天晚上就要用。

大概17:00左右，我聯系深圳那邊同事：勇哥，那臺發布機器被我搞崩了，想問問你重要的文件是不是集中存放在哪，我試試能不能拷貝出來。聯系之后，我基本已經做好了將文件拷貝出來的準備。

17:30，腦子里突然想到，進入了linux修復模式后，奔潰系統的tmp目錄不是/tmp，而是/mnt/sysp_w_picpath/tmp，所以我就進入/mnt/sysp_w_picpath/tmp，發現lib64目錄還在，然后我就mv /mnt/sysp_w_picpath/tmp/lib64 /mnt/sysp_w_picpath/，重啟系統，正常進入。開森。

3.處理生產上的/lib64事故

然后我就在vCenter的存儲上上傳了一個iso鏡像（存儲上沒有鏡像，我們新裝機是走cobbler），可惡，上傳鏡像花了半小時。。這時候已經18:30了，我是有多緊張，20:00就要用這個機器，這個事經理還不知道。。。然后就設置BIOS開機光盤啟動，選擇存儲，前兩次因為選錯了存儲導致沒光盤啟動，后來選對了存儲也還進不去，試了三四次都進不去，我慌了，這是什么問題呢，難道鏡像有問題？沒理由啊，拷貝沒報錯。我就查，查查查，么查到，后來有個人一句話點醒我了：光盤啟動的話，如果你沒有勾選“開機啟動”的話，那就別往下看了。。突然想到，我選了鏡像但是沒有勾選“開機自動掛載”，可不就進不去嘛，真是忙中出錯。一切都處理好了，進入了系統，然后mv /mnt/sysp_w_picpath/tmp/lib64 /mnt/sysp_w_picpath/，重啟，正常進入系統了，但是又有新問題了：密碼明明是正確的，但是提示密碼不正確。

慌亂之中采取了網管的措施，重啟，重啟之后問題依舊，此時是19:00，經理走了，大多數同事都走了，沒人知道我正在處理一個線上事故。。。說實話，這時候我心里怕了，我怕一步一個錯，但是我分析著既然系統都進去了，單用戶模式應該沒問題，改改密碼吧，然后就把系統密碼改成123456，重啟后，正常進入系統了，發現一切都正常，沒問題了吧。。。然后我遠程連接這臺機器，提示超時，回到vmware上，發現系統的sshd服務沒起，查看了這個服務是開機啟動的，然后我就手動起，提示少“libkrb5.so.3”，等于這個libkrb5.so.3庫文件不僅影響了yum，還影響了ssh服務，然后我就又進入linux的修復模式，將鏡像里的libkrb5.so.3拷貝到系統，進入系統后啟動sshd服務正常，遠程連接也行了，但是又有新問題了，只能用root用戶，切普通用戶就卡死，這又是什么問題呢？難道是堡壘機后遺癥（公司用著堡壘機呢，出事故后我就把這臺機器從堡壘機上下了）？然后我就把sshd.config里的關于堡壘機的配置都清空了，還是不行。如果只能連接不能切用戶，深圳那邊的用戶發布代碼還是有問題的，所以這個問題必須解決，但是沒有思路啊。

4.徹底恢復

不能沒有思路就不干啊，最起碼把能干的先干了。把這臺機器加到堡壘機吧，然后再說，不得不說付費的東西就是好用，也不知道什么原理，把這臺機器加到堡壘機后，就能正常切用戶了，這時候已經是20:00多了（代碼因為一些原因延遲發布了），然后我趕緊聯系深圳用戶，讓他看看正常嗎，他回復正常，可算松了一口氣。。。

類似事件：

這個事故出現后不久，又有一臺數據庫因為更換磁盤導致系統起不來了，做的raid10，更換了一塊磁盤，然后系統就崩了（事后分析是raid卡故障導致）。掛載鏡像，進入linux修復模式，系統有五六個分區，不知道問題出在哪個分區，就挨個掛載，發現/boot分區不能掛載，進入/boot分區，發現是空的，也就是說/boot分區文件丟失，查了查資料，說是重裝kernel可以解決，然后就重裝kernel，事實發現不行，然后就從別的機器上拷貝/boot分區內容到崩潰的機器，重啟機器后，不像之前直接進入grub界面了，但是讀完系統進度條后就卡死了，可見還是有問題。這臺數據庫上部署的3M高可用應用，為了快速解決這個問題，選擇了重裝系統并重新部署3M應用。

在此提醒：

1、生產上操作雖然需要手速，但是回車別急著敲。

2、盡量別用rm命令，用mv替代。

3、不確定能處理好的事故，在處理了一段時候后最好上報，不然會特別特別尷尬，不上報吧可能處理不好，上報吧又覺得這么晚才報有點2逼。

linux進入修復模式：

救援模式有什么作用：

◆可以更改root密碼；

◆恢復硬盤、文件系統操作；

◆系統啟動不來的時候，只能通過救援模式來啟動；

救援模式啟動的步驟如下：

1、首先開機進入BIOS設置（每臺電腦進入bios的方法不同根據自己的電腦進入），BOOT啟動順序為光盤優先啟動 CD-ROM Drive 使用小鍵盤的+ -號調整上下順序；設置好后保存并退出。

如果是vmware workstation，可以“虛擬機→電源→開機進入固件”進行設置BIOS；

如果是物理機，直接F1 F2 F12什么的進入BIOS，各有不同，看提示；

如果是exsi，右鍵虛擬機，點編輯，先掛載了鏡像，然后修改開機啟動到BIOS界面即可。

2、重啟系統后進入安裝啟動菜單，上下鍵移動到Rescue install system 救援安裝系統；

3、選擇語言，保持默認English

4、選擇鍵盤類型，保持默認us

5、是否啟動網絡，需要根據你實際情況進行選擇，如果需要通過聯網拷貝數據，選擇YES，在這里我們選擇NO；

6、進入到Rescue界面，選擇Continue

7、本地系統掛載在/mnt/sysp_w_picpath下 如果要到root環境下，運行 chroot /mnt/sysp_w_picpath 命令

8、三種選項：shell 進入命令行模式；fakd是診斷模式；reboot重啟電腦；我們這里選擇shell

9、進入shell命令行，提示符為bash-4.1#

ls /mnt/sysp_w_picpath/ 顯示掛載的目錄為根目錄的文件

執行chroot /mnt/sysp_w_picpath/ 將/mnt/sysp_w_picpath/目錄下的文件移動到根目錄；

命令后提示符為sh-4.1#

ls    顯示為根目錄的文件；

事實上，缺少系統文件會導致“chroot /mnt/sysp_w_picpath”出錯，查也查不出來什么，因為不管缺什么都是統一的錯誤提示“/bin/bash。。。。”，像我上面缺少/lib64目錄、缺少/boot下的文件，在“chroot /mnt/sysp_w_picpath”時都會報錯，而且報錯一樣。。。可以不理會這個命令，你干啥干啥，該修改文件修改文件，該拷貝目錄拷貝目錄，不影響。

10、在sh-4.1#模式下需要先exit退出，回到bash-4.1#才可以reboot重啟系統；