環境：linux 5.4服務器，ORACLE 10.0.2.4數據庫
案情：上週某數據庫DBA做遷移操作時說突然連不上了，向可能有ROOT權限的人確認是否突然修改了密碼。可也太詭異了，這臺數據庫服務器所在的區域安全等級較高，而且運行了若干年從來沒有任何問題。剛剛root放給新入職的DBA就出了問題。還好有堡壘主機，於是立即確認堡壘主機的動作，沒有發現有修改ROOT密碼的命令。驚了一聲冷汗，難不成被***了。
19：30，趕到IDC機房，用顯示器介入發現界面停留在RADHAT登錄界面，但輸入密碼均提示認證失敗;
19：45，嘗試軟關機，但長時間停留在一個界面上半個多小時不動；
20：30，嘗試強制關機，重啓後系統初始化異常；
20：45，嘗試linux單用戶模式修改密碼，結果單用戶模式也進進不了系統，提示錯誤同上；
22：00，懷疑底層文件被刪除，要求二線準備LINUX5.4操作系統光盤趕往機房；
23：00，我們安裝完一臺和故障機同樣操作系統和數據庫的虛擬機，以備萬一故障機恢復不了，我們導出數據文件直接恢復數據庫；
02：00，通過光盤引導linux進入救援模式，我們登錄系統後發現關鍵的數據庫文件目錄還在，頓時放心很多；
02：30，我們發現文件系統底層文件有被移動的跡象，通過堡壘主機的錄像分析瞬間得出結論，應該是操作員用FTP操作時不小心拖動了底層文件/lib64到/media目錄下，而由於/sbin/init是動態鏈接的，造成的表面顯現是/sbin/init不存在；
教訓：root權限一定要收緊，特別是對於新環境不熟悉的老手。
經驗：linux救援模式很重要，必要時可以救人一命，大家要學好。