boot分割槽是系統啟動中最重要的部分,如果伺服器由於病毒攻擊又或者被管理員誤刪除了boot分割槽。那麼就會存在潛在的風險。為什麼說是潛在的風險?因為boot分割槽被刪除後系統仍在繼續執行,看似無狀況但是在執行關機操作後就會無法啟動。
1.掛載centos系統映象
2.進入救援模式
3.修復fstab檔案
4.再次進入救援模式
5.從新安裝核心檔案
6.安裝grub
7.手動修復grub
8.重啟進入系統
1.首先檢視系統的磁碟情況,根目錄在邏輯卷,boot分割槽為普通檔案系統。注:boot分割槽只能在基本檔案系統。
然後將fstab檔案移出,將boot分割槽下所有檔案刪除,模擬系統出現故障。確認boot分割槽下沒有任何檔案。
2.重新啟動作業系統會出現如下圖所示,為什麼這個磁碟裝置連boot分割槽都沒了系統還將這個裝置當做啟動裝置呢?那是因為bios根據設定好的順序尋找第乙個有mbr資訊的磁碟裝置,只要有mbr資訊不論能不能啟動都會把這個裝置當做啟動裝置。如圖所示即/boot分割槽與fstab檔案全部丟失的情況
3.再重新啟動,設定bios優先從光碟啟動,然後選擇第三個,進入救援模式
4.一路回車一路yes,直到下圖所示選擇no不開啟網路功能,因為這次主要演示從光碟的救援模式修復,所以沒有必要啟動網路服務。如果當前環境下沒有光碟機,那麼可以開啟網路服務進行修復,網路修復等下次再演示。
5.救援系統啟動後有乙個任務就是將你原作業系統的根掛在到救援系統中/mnt/sysimage。由於fstab檔案也被我刪除了,所以救援系統無法找到原系統的磁碟路徑,也就談不上掛載原系統的根了,所以首要任務就是先修復/etc/fstab檔案。
6.使用blkid
命令檢視當前系統中的裝置資訊,發現只有2個分割槽。乙個為ext4格式,乙個為邏輯卷格式。我這裡搭建的環境比較簡單如果在生產中應該會有多個分割槽。從圖上新資訊分析出/dev/sda1
為boot分割槽,/dev/sda2
捲組。
7.既然知道根分割槽在在邏輯卷中,那麼使用lvdispaly
命令檢視邏輯卷分割槽。黃色框中說明邏輯卷是非啟用狀態。
8.lvsacn
檢視邏輯卷的狀態,此時顯示為非啟用狀態。vgchange -ay
啟用所有邏輯卷。lvscan
再次檢視邏輯卷狀態,對比第一次已經從inactive變為active(啟用)
9.再使用blkid
命令檢視裝置資訊,發現多了2個裝置資訊,這就是邏啟用邏輯卷後顯示出來的。如果分割槽多的話那就通過手動逐一掛載後進到分割槽中去,檢視分割槽中的各目錄分析各分割槽的作用。在這裡很容易分辨出乙個是root分割槽乙個是swap分割槽。
10.建立掛載點,將root分割槽掛載至掛載點
11.手動建立fstab檔案,按照fstab檔案的格式填寫相應的分割槽資訊
12.重新啟動後再次進入救援模式,救援模式會提示將原作業系統的根掛載到/mnt/sysimage,此時標誌著/etc/fstab檔案已經修復完成
13.進入救援模式,首先要切根,然後掛在光碟,安裝kernel檔案
14.檢視boot分割槽,目錄內出現一堆檔案,包括內和檔案與偽根檔案系統表明kernel安裝完成
15.安裝grub,安裝時指定磁碟裝置,而不是分割槽。然後sync同步分割槽一定要多同步幾次。
16.再次檢視boo分割槽,如果出現grub目錄,就表示grub已經安裝完成。
17.手動建立grub,紅色框中為設定根目錄,一定要寫根分割槽而不是磁碟。
18.再次開機出現grub介面,按下回車系統正常啟動!
Linux系統中boot分割槽的恢復方法
1 模擬問題,刪除boot目錄 2 重啟系統,出現以下介面 3 強制關閉系統,進入挽救模式 4 掛載光碟機檔案 5 grub2 install dev sda 安裝裝置 fdisk l 檢視到的 在哪寫哪 cd opt lscp packages kernel 3.10.0 514 el7.x86 ...
使用Ghost錯選恢復分割槽後的恢復方法
為了對付 變化無常 的windows系統,我們經常會使用ghost軟體,備份乙個擴充套件名為.gho的檔案,當windows系統出現意外時,再用ghost的 from image to 分割槽 來對系統進行恢復,這樣就可以省去繁瑣耗時的重新安裝作業系統的工作。但是,在使用 from image to...
AWS災難恢復方案示例 (1)備份和恢復
前面我們介紹了關於disaster recovery dr 的內容包括 disaster recovery dr 災難恢復的定義和內容概述 恢復時間目標 rto 和 恢復點目標 rpo 與災難恢復 dr 相關的aws功能和服務 1 與災難恢復 dr 相關的aws功能和服務 2 與災難恢復 dr 相關...