PC 上的 LVM 灾难修复-白红宇

PC 上的 LVM 灾难修复

阅读量：5946 次

发布时间：2019-06-19

本文共 15733 字，大约阅读时间需要 52 分钟。

原文链接：http://www.ibm.com/developerworks/cn/linux/l-cn-pclvm-rstr/

毛伟, 软件工程师, IBM

李瑞, 软件工程师, IBM

于晶, 软件工程师, IBM

简介：硬盘单碟容量的快速增长和价格快速下降，为普通 PC 提供了丰富的存储空间，也带来的存储管理的需求。对于缺少昂贵硬件支撑的普通 PC 用户，Linux 上的 LVM 是一个理想的选择。对服务器用户而言，LVM 可以构建在基于 Raid 的磁盘组上，通过硬件冗余实现容灾；对于普通 PC 用户来说，可能没有那么多银子来实施，那么我们就不得不面对各种各样的窘境，譬如逻辑卷损坏，磁盘坏道，硬盘位置更改，硬盘损坏等等。好在 LVM 的开发者在设计中就包含了这些考虑，提供了一系列的方法来帮助我们解决这些问题，把数据损失降到最低。本文结合实例，分析和解决 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 版本

rpm -qa | grep 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. 检查磁盘及文件系统状况

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:~ # 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

linux-c3k3:~ # pvcreate -ff /dev/sdb

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 对应标签并查看状态

linux-c3k3:~ # dd if=/dev/zero f=/dev/sdb bs=512 count=1 seek=1

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'.

......

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. 以只读方式挂载并备份

linux-c3k3:~ # mount -o remount -o ro /alpha

（备份操作略）

下面我们来尝试修复

清单 6. 修复操作

* 如果出现 Can't open /dev/sdb exclusively. Mounted filesystem? 的情况请先 deactive 你的 vg

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. 检查磁盘及文件系统状况

(none):/test # pvs

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 信息

(none):/etc/lvm/backup # cp * /testback/

我们用 dd 命令把 /dev/sdc 的前 400 个扇区都清零（包括 LVM2 label、meta. data、分区表等）

清单 9. 应用 dd 模拟故障状态

(none):/ # dd if=/dev/zero f=/dev/sdc bs=512 count=400

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'.

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 损坏分区

(none):~ # mount /dev/test/lv0 /test

mount: you must specify the filesystem type

文件系统已经损坏 .

这里我们尝试进行替换，以 sdd 替换 sdc

清单 11. 故障卷的替换

(none):/ # pvcreate --restorefile /etc/lvm/backup/test \n

--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

(none):/ # vgchange -an test

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. 重新挂载

(none):~ # mount /dev/test/lv0 /test

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):~ # mount /dev/test/lv0 /test

(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. 导入并激活卷组

* 扫描 PV

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 Login: root

Rescue:~#

执行如下命令检查当前状态：

清单 20. 检查磁盘及文件系统状况

Rescue:~#lvscan

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'.

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. 删除缺失的物理卷

Rescue:~#vgreduce – removemissing 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 all physical volumes for volume group system.

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. 激活修复后的卷

Rescue:~#lvscan

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 分区磁盘损坏的操作步骤，就可以让卷组恢复正常。将恢复后的卷组挂载后，就可以执行正常读写了。