PC 上的 LVM 灾难修复

 

http://kb.cnblogs.com/page/86830/

 

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 lvmlvm2-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 of=/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'.  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. 以只读方式挂载并备份

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 of=/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'.  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 损坏分区

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