PC 上的 LVM 災難修復
LVM 介紹
LVM 簡介
LVM 是邏輯盤卷管理（Logical Volume Manager）的簡稱，最早是 IBM 為 AIX 研發的存儲管理機制。LVM 通過在硬盤和分區之間建立一個邏輯層，可以讓多個分區或者物理硬盤作為一個邏輯卷 ( 相當于一個邏輯硬盤 )，提高了磁盤分區管理的靈活性。1998 年，Heinz Mauelshagen 在 Linux 2.4 內核上提供了 Linux 的 LVM 實現。目前 Linux 2.6 內核支持 LVM2，Redhat 官方網站目前提供最新可下載版本為 2.2.02.77；如果需要最新或者其它版本，請參考網頁。
LVM 早期多用于服務器，配合存儲硬件的 Raid 技術，提供高可靠性，可靈活配置的磁盤分區管理；普通 PC 由于存儲容量有限，很少使用這種技術。隨著單個磁盤容量的不斷擴大和硬盤價格的下降，普通 PC 擁有 TB 級的大容量存儲空間逐漸普及，也帶來對 PC 上存儲管理的需要，LVM 無疑是很好的解決方案。只是普通 PC 用戶由于缺少硬件冗余保護，在發生災難時，通常會發生比較嚴重的數據損失。好在 LVM 提供了一系列災難恢復的功能，可以幫助普通 PC 用戶盡可能減少損失。
我們可以通過下面的命令檢查系統中是否安裝了 lvm 工具：
清單 1. 查看系統中 LVM 版本
lvm2-2.02.56-8.el5_5.4
上例系統安裝了 2.02.56 版本的 LVM。LVM 的基本概念 pv/lv/vg/vgda
硬盤存儲設備進行管理 , 相關的概念和命令相對多，下面我們對 LVM 的相關名詞進行解釋以方便讀者更好理解。
物理卷 physical volumes（PV）
物理卷處于邏輯卷管理器中的底層，任何的邏輯卷和卷組都必需依靠物理卷來建立；物理卷可以是一個完整的硬盤，也可以是硬盤中的一個分區，并有一個名字 ( 如 hdisk0)。
邏輯卷 logical volumes （LV）
邏輯卷建立在卷組之上，卷組中的空間可以建立多個邏輯卷，并且邏輯卷可以隨意在卷組的空閑空間中增減，邏輯卷可以屬于一個卷組，也可以屬于不同的多個卷組。LV 是位于 PV 上的信息的組合，在 LV 上的數據可以連續或者不連續地出現在 PV。
卷組 logical volume group（VG）
卷組是建立在物理卷之上，一個卷組中可以包含一個物理卷組或者多個物理卷。所有的物理卷屬于一個稱作 rootvg 的卷組。
卷組描述區域 Volume Group Descriptor Area （VGDA）
用于描述物理卷、卷組、邏輯卷分配的所由信息。和非 LVM 系統將包含分區信息的元數據保存在位于分區的起始位置的分區表中一樣，邏輯卷以及卷組相關的元數據也是保存在位于物理卷起始處的 VGDA( 卷組描述符區域 ) 中。
圖 1. Linux LVM 架構圖
LVM 災難修復基本思路
災難的類型
文件系統災難一般可以分為兩類——人為災難和自然災難。人為災難主要是人為操作導致的數據丟失，分區損壞，分區表損壞等等，自然災難主要是由于事故、意外事件或者自然損耗導致的磁盤壞道，磁盤損壞，相關硬件損壞導致的磁盤位置調整等等。
由于 LVM 和普通文件系統的硬件環境并沒有什么區別，所以他們所面對的自然災難類型也是一致的。但是對于 LVM 而言，通過虛擬化存儲管理帶來分區容量動態調整便利的同時，也帶來了一些 LVM 特有的人為災難。如第一章所說，LVM 將所有磁盤創建為物理卷置于卷組中統一管理，然后創建邏輯卷供操作系統調用，這也就導致可能出現卷組損壞，邏輯卷損壞，物理卷損壞等災難。
修復的策略
對于企業用戶而言，通常會制定嚴格的操作規章制度來和完備的備份策略來抵御人為災難，還有完整的硬件冗余方案來對抗自然災難；對于普通用戶而言，一般都不具備這種客觀條件來防范災難。一旦發生災難，我們所要做的是盡量減少災難的影響，盡可能恢復災難所造成的數據損失。
對于 LVM 的人為災難恢復而言，LVM 本身提供了數據備份和配置信息備份的工具，可以充分利用這些工具進行備份，在發生人為災難導致物理卷錯誤，邏輯卷錯誤和卷組錯誤的時候，利用備份進行恢復，盡可能恢復災難所導致的數據損失。
由于 LVM 將所有磁盤進行統一管理，磁盤損壞會導致整個文件系統不可使用，因為自然恢復的主要目標是在災難發生后恢復 LVM 的可用性，恢復正常磁盤上的可用數據。LVM 本身提供了一套工具，用戶可以通過這套工具解決絕大多數由于硬件故障導致的 LVM 不可用的問題，在自然災難發生后盡可能恢復 LVM 的可用性。在某些情況下，由于人為災難造成 LVM 發生卷組、物理卷或者邏輯卷不一致的情況，進而導致部分邏輯卷、甚至整個卷組無法訪問的情況，修復此類問題也可以通過上述工具來進行。
LVM 的災難恢復
本節將結合具體災難，演示如何進行 LVM 災難恢復。為了便于演示，我們假設試驗環境如下：基于 X86 架構的 PC，除硬盤外所有硬件均能正常穩定的工作，PC 上安裝了 2 塊磁盤 Disk-A 和 Disk-B。
邏輯卷損壞
硬盤的邏輯損壞的原因往往是多種多樣的，可能是誤操作，可能是不正常掉電，也可能是病毒甚至匯編語言的 diskkiller 直接造成。但這些損壞大都并非是不可逆的，下面我們就將在實驗用 PC 上模擬一些常見的錯誤并進行恢復操作。
先來看看當前的磁盤及文件系統狀況：
清單 2. 檢查磁盤及文件系統狀況
PV VG Fmt Attr PSize PFree
/dev/sdb system lvm2 a- 2.00G 92.00M
/dev/sdc system lvm2 a- 2.00G 0
linux-c3k3:~ # vgs
VG #PV #LV #SN Attr VSize VFree
system 2 1 0 wz--n- 4.00G 92.00M
linux-c3k3:~ # lvs -o +devices
LV VG Attr LSize Origin Snap% Move Log Copy% Devices
alpha system -wi-ao 3.90G /dev/sdc(0)
alpha system -wi-ao 3.90G /dev/sdb(0)
linux-c3k3:~ # mount |grep '/dev/mapper'
/dev/mapper/system-alpha on /alpha type reiserfs (rw,acl,user_xattr)
接著我們將模擬一些錯誤情況：
情況 1: 文件系統正常，硬盤無物理故障的狀況
在這之前我們先確認一些狀況，請確認你的 root 分區不在 lvm 的管理范圍內，否則一旦 lvm 系統出現故障，整個系統將無法啟動，雖然通過光盤 rescure 模式啟動可以進行一定的操作，但會造成很多不必要的麻煩。如果在平時的使用中你已經將 root 分區置于 lvm 管理之下，那么請定期備份 /etc/lve/backup/ 下的文件用以系統恢復，否則即使硬盤沒有物理損壞，而只是 lvm 邏輯標簽對應錯誤，你的數據也很有可能救不回來了。當然，即使 root 分區不在 lvm 的管理范圍內，定期備份該目錄也是一個很好的習慣
清單 3. 嘗試應用存在邏輯卷的 pv
Really INITIALIZE physical volume "/dev/sdb" of volume group "system" [y/n]? y
Can't open /dev/sdb exclusively. Mounted filesystem?
可以看到 pvcreate 拒絕對那些上面有邏輯卷的 pv，如果要執行該操作的話需要把上面的邏輯卷刪除，該命令后面將會用到。現在我們用 dd 命令擦除 sdb 對應 lvm2 的標簽但保留分區表（操作有一定風險，請謹慎嘗試）
清單 4. 擦除 lvm2 對應標簽并查看狀態
1+0 records in
1+0 records out
512 bytes (512 B) copied, 9.8e-05 seconds, 5.2 MB/s
linux-c3k3:~ # pvs --partial
Partial mode. Incomplete volume groups will be activated read-only.
Couldn't find device with uuid '7m0QBR-3kNP-J0fq-GwAq-iv6u-LQkF-yhJh5R'.
Couldn't find device with uuid '7m0QBR-3kNP-J0fq-GwAq-iv6u-LQkF-yhJh5R'.
Couldn't find device with uuid '7m0QBR-3kNP-J0fq-GwAq-iv6u-LQkF-yhJh5R'.
......
PV VG Fmt Attr PSize PFree
/dev/sdc system lvm2 a- 2.00G 0
unknown device system lvm2 a- 2.00G 92.00M
linux-c3k3:~ # vgs --partial
Partial mode. Incomplete volume groups will be activated read-only.
Couldn't find device with uuid '7m0QBR-3kNP-J0fq-GwAq-iv6u-LQkF-yhJh5R'.
......
VG #PV #LV #SN Attr VSize VFree
system 2 1 0 rz-pn- 4.00G 92.00M
linux-c3k3:~ # lvs --partial
Partial mode. Incomplete volume groups will be activated read-only.
Couldn't find device with uuid '7m0QBR-3kNP-J0fq-GwAq-iv6u-LQkF-yhJh5R'.
......
LV VG Attr LSize Origin Snap% Move Log Copy%
alpha system -wi-ao 3.90G
從上面的情況我們不難看出 sdb 已經變成了未知設備，卷組的 metadata 變成只讀的了，且是 partial 的狀態，但 lv 的情況還是基本正常的。其實，在這種情況下，還是可以掛載、訪問故障的文件系統的，畢竟分區表本身并沒有損壞。于是我們首先要做的無疑是備份（最好以只讀方式掛載）
清單 5. 以只讀方式掛載并備份
（備份操作略）
下面我們來嘗試修復
清單 6. 修復操作
linux-c3k3: ~ # pvcreate -ff --uuid 7m0QBR-3kNP-J0fq-GwAq-iv6u-LQkF-yhJh5R \n
--restorefile /etc/lvm/backup/system /dev/sdb
Couldn't find device with uuid '7m0QBR-3kNP-J0fq-GwAq-iv6u-LQkF-yhJh5R '.
Physical volume "/dev/sbd" successfully created
linux-c3k3:~ # pvs
PV VG Fmt Attr PSize PFree
/dev/sdb system lvm2 a- 2.00G 92.00M
/dev/sdc system lvm2 a- 2.00G 0
* 恢復成功，然后我們繼續對卷組進行恢復
linux-c3k3: ~ # vgcfgrestore -f /etc/lvm/backup/system system
Restored volume system
* 卷組完成恢復，然后激活后查看
linux-c3k3: ~ #vgchange – ay system
1 logical volume(s) in volume group "system" now active
到此處為止，你會發現，一切正常了，數據也沒有任何的損失，但為了保險起見還是應該嘗試進行一下文件系統掃描以確保萬無一失。回頭看我們前面提到的如果 root 分區在 lvm 管理下的情況，會出現系統無法啟動的情況，這時候怎么辦呢？
其實也不是無法解決的，是用操作系統盤引導，進入 Rescure 模式，利用你之前備份的 /etc/lve/backup/ 下的文件進行恢復即可，如果你需要先啟動起原本的系統以取出備份文件，可以使用 vgreduce – removemissing system 命令去掉丟失標簽的物理磁盤再啟動，而后利用備份文件執行恢復操作，但是每次正常的 lvm 啟動都會更改 /etc/lve/backup/ 下的內容，這也是為什么我們需要對其內容進行備份的原因。如果很不幸的你沒有備份 /etc/lve/backup/ 下的內容，且 root 分區在 lvm 管理下的情況，那么很遺憾，即使你的硬盤沒有物理損毀，你的數據也很難救回了，針對這種情況向系統的恢復方法，請參照 3.4 磁盤損壞 部分進行操作。
情況 2：PV 的損壞與替換
先看一下系統的情況
清單 7. 檢查磁盤及文件系統狀況
PV VG Fmt Attr PSize PFree
/dev/sda2 system lvm2 a- 7.93G 0
/dev/sdb test lvm2 a- 2.00G 0
/dev/sdc test lvm2 a- 2.00G 0
/dev/sdd lvm2 -- 2.00G 2.00G
(none):/test # vgs
VG #PV #LV #SN Attr VSize VFree
system 1 2 0 wz--n- 7.93G 0
test 2 1 0 wz--n- 3.99G 0
(none):/test # lvs
LV VG Attr LSize Origin Snap% Move Log Copy%
root system -wi-ao 7.38G
swap system -wi-ao 560.00M
lv0 test -wi-ao 3.99G
(none):/test # (none):/ # mount /dev/test/lv0 /test/
(none):/ # ls /test
doc.txt
(none):/ # umount /test
我們在 lv0 下存儲了一個文件，備份一下 /etc/lvm/backup 的文件
清單 8. 備份 Lvm 信息
我們用 dd 命令把 /dev/sdc 的前 400 個扇區都清零（包括 LVM2 label、meta data、分區表等）
清單 9. 應用 dd 模擬故障狀態
400+0 records in
400+0 records out
204800 bytes (205 kB) copied, 0.046619 seconds, 4.4 MB/s
(none):/ # pvs --partial
Partial mode. Incomplete volume groups will be activated read-only.
Couldn't find device with uuid 'noOzjf-8bk2-HJhC-92fl-2f6Q-DzNZ-XBqnBO'.
Couldn't find device with uuid 'noOzjf-8bk2-HJhC-92fl-2f6Q-DzNZ-XBqnBO'.
Couldn't find device with uuid 'noOzjf-8bk2-HJhC-92fl-2f6Q-DzNZ-XBqnBO'.
Couldn't find device with uuid 'noOzjf-8bk2-HJhC-92fl-2f6Q-DzNZ-XBqnBO'.
Couldn't find device with uuid 'noOzjf-8bk2-HJhC-92fl-2f6Q-DzNZ-XBqnBO'.
Couldn't find device with uuid 'noOzjf-8bk2-HJhC-92fl-2f6Q-DzNZ-XBqnBO'.
PV VG Fmt Attr PSize PFree
/dev/sda2 system lvm2 a- 7.93G 0
/dev/sdb test lvm2 a- 2.00G 0
/dev/sdd lvm2 -- 2.00G 2.00G
unknown device test lvm2 a- 2.00G 0
這種情況下想要完全恢復可能比較困難了，如果無意找回還可能存在的數據，請參照 3.4 磁盤損壞 部分進行操作。如想盡可能多的找回數據，請先嘗試 mount，
清單 10. 嘗試 mount 損壞分區
mount: you must specify the filesystem type
文件系統已經損壞。這里我們嘗試進行替換，以 sdd 替換 sdc
清單 11. 故障卷的替
--uuid noOzjf-8bk2-HJhC-92fl-2f6Q-DzNZ-XBqnBO /dev/sdd
Couldn't find device with uuid 'noOzjf-8bk2-HJhC-92fl-2f6Q-DzNZ-XBqnBO'.
Physical volume "/dev/sdd" successfully created.
(none):/ # pvs -v
Scanning for physical volume names
Wiping cache of LVM-capable devices
PV VG Fmt Attr PSize PFree DevSize PV UUID
/dev/sda2 system lvm2 a- 7.93G 0 7.93G HsErSz-vuAD-rEe1-wE5m-Mnvr-T0Re-EwO7rD
/dev/sdb test lvm2 a- 2.00G 0 2.00G OBb3qb-TW97-hKZ7-vmsr-RZ2v-fzuP-qK3wmN
/dev/sdd test lvm2 a- 2.00G 0 2.00G noOzjf-8bk2-HJhC-92fl-2f6Q-DzNZ-XBqnBO
我們可以看到 sdd 已經替換了 sdc。不過這時候 /etc/lvm/backup 下的文件并不會更新，同時會看到如下的情況
清單 12. 同步 metadata
Volume group test metadata is inconsistent
Volume group for uuid not found:
tcyuXvjcxCN7912qAJlEYzphncdWabTJ21OTTrG6DrMS8dPF5Wlh04GOHyO5ClbY
1 logical volume(s) in volume group "test" now active
* 即報告 vg 的 metadata 不一致
* 重新啟動系統
(none):~ # vgchange -an test
0 logical volume(s) in volume group "test" now active
(none):~ # vgchange -ay test
1 logical volume(s) in volume group "test" now active
已不存在該問題，這時候 /etc/lvm/backup 也已經更新了。
之后嘗試 mount
清單 13. 重新掛載
mount: you must specify the filesystem type
我們開始嘗試修復文件系統
經過
reiserfsck /dev/test/lv0 --check
reiserfsck /dev/test/lv0 --rebuild-sb
reiserfsck /dev/test/lv0 --check
reiserfsck /dev/test/lv0 --rebuild-tree
reiserfsck /dev/test/lv0 - – check
命令之后（實際需要執行的情況依據硬盤受損情況可能有所不同）
清單 14. 查看修復后的狀態
(none):~ # cd /test
(none):/test # ls
doc.txt .doc.txt.swp lost+found
(none):/test #
很幸運，我們的文件還在。
磁盤壞道
硬盤長時間的使用，非正常操作或電源管理失誤都可能造成磁盤壞道的產生。最典型的癥狀就是一旦對硬盤的某一部分進行操作，就會出現整個硬盤停止工作，如果操作系統也在該硬盤上，那么系統立即崩潰也就成為了必然。這還不是最可怕的，因為壞道一旦產生就有擴散的可能，每次觸及，導致的 crash 都比一次系統非正常掉電造成的傷害更為嚴重，除了壞道的擴散外還很有可能破壞整塊硬盤的動平衡，從而導致整個硬盤不可恢復的物理性損壞。可見，及時發現硬盤壞道，并盡早處理是十分必要的。
LVM 自己本身其實有一套對壞道的處理機制：
硬盤內部的數據重定位：最底層的重定位，發生在磁盤內部，出現的時候不會通知用戶。
由 LVM 產生的硬件重定位：更高層次的重定位，LVM 將有問題的物理地址 A 上的數據拷貝到物理地址 B，LVM 會繼續讀地址 A 上的數據，但是硬盤已經將真實的 IO 轉向物理地址 B。
軟件重定位：最高層次的重定位，也由 LVM 設備產生。LVM 生成一個壞道表，當讀物理地址 A 上的數據時，先檢查壞道表，如果 A 在壞道表中，就轉向物理地址 B。
但以上這些，其實對用戶都是透明的，用戶可以在創建 lv 時通過 lvcreate – r n 參數關閉這樣，系統將不創建壞塊重定位區域（BBRA)，引導、根和主交換邏輯卷必須使用此參數。當用戶覺得 LVM 有問題的時候，首先要做的事情就是備份，盡可能地保存卷組中的數據。卷組發生問題后進行的備份需要和發生問題前進行的備份進行對比。針對存在壞道的情況，fsck 一定要慎用，尤其對于重定位已經無法處理的應盡快將硬盤導出（操作見 3.3 磁盤位置更改部分）LVM 以防壞道擴散，如在導出過程中出現問題，請比照 3.4 磁盤損壞處理。
磁盤位置更改
主板端口損壞、更歡 PC 主板、添加新的設備都可能導致磁盤位置更改的發生。由于 Linux 的主引導記錄（MBR）一般記錄在第一塊磁盤的第一個扇區上，如果第一塊磁盤的順序發生改變，會導致系統無法啟動。對于這種情況，只需要調整磁盤順序就可以解決（只需要保證有 MBR 的磁盤排在第一順位就可以，不一定是總線的第一個端口）。這里討論兩種比較常見的情況，磁盤在系統內位置更改和磁盤在系統間移動。
磁盤在系統內移動
對于單一卷組的 LVM 文件系統而言，LVM 能夠自動識別出磁盤位置的更改。磁盤位置更改后，正常啟動系統就可以正常訪問了。當系統中存在單獨的卷組，或者系統中存在多個卷組是，更改磁盤位置前需要停用卷組，在完成磁盤移動后需要重新激活卷組，執行操作如下：
清單 15. 重新激活卷組
Linux:~# vgchange – a n /dev/system
0 logical volume(s) in volume group “system” now active
Linux:~#lvscan
Inactive '/dev/system/test'[1.90 GB] inherit
* 激活卷組：
Linux:~# vgchange – a n /dev/system
1 logical volume(s) in volume group “system” now active
Linux:~#lvscan
ACTIVE '/dev/system/test'[1.90 GB] inherit
磁盤在系統間移動
當磁盤在系統間移動的時候，除了需要停用激活卷組外，還需要執行卷組導出 / 倒入的操作。
清單 16. 導出卷組
* 停用卷組：
Linux:~# vgchange – a n /dev/system
0 logical volume(s) in volume group “system” now active
* 導出卷組
Linux:~# vgexport /dev/system
Volume group “system” successfully exported
此時就可以將磁盤移動到其他系統。
清單 17. 導入并激活卷組
Linux:~# pvscan
PV /dev/sdc is in exported VG system [2.00 GB / 96.00 MB free]
Total: 1 [2.00 GB] / in use: 1 [2.00 GB] / in no VG: 0[0 ]
* 導入 VG
Linux:~# vgimport /dev/system
Volume group “system” successfully imported
* 激活卷組
Linux:~# vgchange – a n /dev/system
1 logical volume(s) in volume group “system” now active
到此，卷組就可以恢復正常了。某些卷組可能是跨多塊磁盤建立的，而磁盤移動可能只是針對其中的某些磁盤。在這種情況下，可以執行 pvmove 命令，把數據移動到指定磁盤上，然后針對指定磁盤執行移動操作。
磁盤損壞
對于普通 PC 而言，多塊磁盤的主要目的是擴充存儲容量，一般不會采用 RAID 方案來應對磁盤損壞。一旦發生磁盤損壞的情況，用戶在承受損壞硬盤上面的所有數據丟失之痛的時候，最不愿看到的就是剩下的磁盤也沒法訪問的情況。好在 LVM 的開發者充分考慮了這一點，為 LVM 提供了恢復機制。
當 root 分區不是創建在 LVM 上時，情況就如同普通的磁盤損壞一樣，只需要更換磁盤，重裝系統，然后將原來的 LVM 分區重新掛載就可以，和掛載其它類型的文件系統并沒有什么區別，在此不作贅述。當 root 分區創建在 LVM 上時，我們還需要分兩種情況來處理—— root 分區所在的磁盤損壞和非 root 分區所在的磁盤損壞。
非 root 分區磁盤損壞
用 Disk-A 和 Disk-B 創建 System VG，root 分區和交換分區存在于 Disk-A 上，Disk-A 和 Disk-B 上創建了多個 LV 用于存放用戶數據。當用戶在某次重起后，發現系統無法起動，經檢查發現 Disk-B 損壞，用戶希望能夠啟動系統，恢復 Disk-A 上的數據。
移除損壞磁盤 Disk-B 后，系統無法啟動，系統輸出如下：
清單 18. 磁盤損壞后狀態
Reading all physical volumes. This may take a while …
Couldn' t find device with uuid 'wWnmiu-IdIw-K1P6-u10C-A4j1-LQSZ-c08RDy ' .
Couldn' t find all physical volumes for volume group system.
Couldn' t find device with uuid 'wWnmiu-IdIw-K1P6-u10C-A4j1-LQSZ-c08RDy' .
Couldn' t find all physical volumes for volume group system.
Volume group “system” not found
Couldn't find device with uuid 'wWnmiu-IdIw-K1P6-u10C-A4j1-LQSZ-c08RDy' .
Couldn't find all physical volumes for volume group system.
Couldn't find device with uuid 'wWnmiu-IdIw-K1P6-u10C-A4j1-LQSZ-c08RDy' .
Couldn't find all physical volumes for volume group system.
.not found -- exiting to /bin/sh
分析輸出可知，該問題是磁盤 Disk-B 損壞導致的。究其原因，是 root 分區創建于 LVM 上，當硬盤丟失時，導致 LVM 的發生不一致，導致 root 分區無法被正常讀取，進而系統無法正常啟動。如果能夠恢復 LVM 的一致性，恢復 root 分區的正常讀取，就可以恢復 Disk-A 上的數據。
由于此時系統已經不能正常啟動，需要用光盤啟動進入到緊急恢復模式，用 root 用戶登錄：
清單 19. 緊急恢復登陸
Rescue:~#
執行如下命令檢查當前狀態：
清單 20. 檢查磁盤及文件系統狀況
Reading all physical volumes. This may take a while …
Couldn't find device with uuid 'wWnmiu-IdIw-K1P6-u10C-A4j1-LQSZ-c08RDy'.
Couldn't find all physical volumes for volume group system.
Couldn't find device with uuid 'wWnmiu-IdIw-K1P6-u10C-A4j1-LQSZ-c08RDy'.
Couldn't find all physical volumes for volume group system.
Volume group “system” not found
Rescue:~#pvscan
Couldn't find device with uuid 'wWnmiu-IdIw-K1P6-u10C-A4j1-LQSZ-c08RDy'.
Couldn't find device with uuid 'wWnmiu-IdIw-K1P6-u10C-A4j1-LQSZ-c08RDy'.
PV /dev/sda2 VG system lvm2 [7.93 GB / 0 free]
PV unknown VG system lvm2 [2.00 GB / 2.00 GB free]
Total: 2 [9.92 GB] / in use: 2 [9.92 GB] / in no VG: 0 [0 ]
由上面輸出可以知道，由于磁盤缺失，系統無法正確識別 system 卷組，但是系統可以正確識別出硬盤，也可以檢測到硬盤的缺失。當系統掛載的是普通文件系統的時候，我們可以通過緊急恢復模式下直接掛載文件系統的方法來進行數據恢復，然而這種方法在 LVM 下行不通，因為所有的邏輯卷都是 LVM 管理的，當卷組不能被正確識別的時候，所有的 LV 也不能被處理。因此我們要做的就是刪除卷組中的缺失物理盤，恢復卷組的一致性。
LVM 提供 vgreduce 來執行從卷組中刪除物理卷的操作，并且提供”— removemissing”來刪除卷組中所有缺失的物理卷。
清單 21. 刪除缺失的物理卷
Couldn't find device with uuid 'wWnmiu-IdIw-K1P6-u10C-A4j1-LQSZ-c08RDy'.
Couldn't find all physical volumes for volume group system.
Couldn't find device with uuid 'wWnmiu-IdIw-K1P6-u10C-A4j1-LQSZ-c08RDy'.
Couldn't find all physical volumes for volume group system.
Couldn't find device with uuid 'wWnmiu-IdIw-K1P6-u10C-A4j1-LQSZ-c08RDy'.
Couldn't find device with uuid 'wWnmiu-IdIw-K1P6-u10C-A4j1-LQSZ-c08RDy'.
Wrote out consistent volume group system
Rescue:~#vgscan
Reading all physical volumes. This may take a while …
Found volume group “system” using metadata type lvm2
Rescue:~#pvscan
PV /dev/sda2 VG system lvm2 [7.93 GB / 0 free]
Total: 1 [7.93 GB] / in use: 1 [7.93 GB] / in no VG: 0 [0 ]
通過刪除缺失的硬盤，此時系統已經可以正確識別卷組。但是經歷過如此劫難，LV 還需要額外的步驟才能正常工作。執行 lvscan，我們可以發現 root 和 swap 兩個邏輯卷都處于 inactive 狀態，需要手動執行 lvchange 命令激活，才能使它正常工作。
清單 22. 激活修復后的卷
inactive '/dev/system/root'[7.38 GB] inherit
inactive '/dev/system/swap'[560.00 MB] inherit
Rescue:~#lvchange – ay /dev/system
ACTIVE '/dev/system/root'[7.38 GB] inherit
ACTIVE '/dev/system/swap'[560.00 MB] inherit
到此，大功告成，重起，系統啟動，除了損壞的磁盤已經一去不復返以外，系統又恢復正常了。
root 分區磁盤損壞
當 root 分區磁盤發生損壞的時候，唯一的選擇只能是另外找一臺機器，把沒有損壞的磁盤裝上去。開機后執行 `fdisk – l`，輸出顯示硬盤不包含有效分區表，不能夠正確讀取。執行 LVM 的相關檢查，可以注意到錯誤信息與非 root 分區輸出的一致。執行非 root 分區磁盤損壞的操作步驟，就可以讓卷組恢復正常。將恢復后的卷組掛載后，就可以執行正常讀寫了。
總結
對于運行在普通 PC 上的 LVM，通常缺少有計劃的備份和硬件冗余來應對災難，因而在災難發生時，往往需要承受嚴重的數據損失。本文介紹了 LVM 上可能發生的災難，結合實例演示了如何進行災難恢復，在 LVM 遇到災難時，可以盡可能恢復數據，減少損失。
留言列表
