基于LVM的数据恢复技术研究——场景1：lvm信息丢失；场景2：LUN盘无法识别

基于LVM的数据恢复技术研究——场景1：lvm信息丢失；场景2：LUN盘无法识别

LVM是 Logical Volume Manager(逻辑卷管理)的简写。LVM将一个或多个硬盘的分区在逻辑上集合，相当于一个大硬盘来使用，当硬盘的空间不够使用的时候，可以继续将其它的硬盘的分区加入其中，这样可以实现磁盘空间的动态管理，相对于普通的磁盘分区有很大的灵活性。（ 详见附件 红帽官网 LOGICAL VOLUME MANAGER ADMINISTRATION （RedHat 7 ） ）

在实际使用中，可能因LVM信息或数据区域丢失，导致文件系统启动、初始化、识别等过程失败，造成文件系统不可用，故针对此，研究四种常见的故障场景，以应对数据丢失风险。分为两篇，本文将分享对前两种场景的分析。

场景1：磁盘头部的lvm信息不慎丢掉

一、 故障描述：

某个LUN盘上的lvm信息突然丢失，可能是磁盘拷贝等原因，导致盘头信息的丢失，仅有少量数据丢失，大部分数据仍存在。

二、 测试方式：

初始化环境，使用一块盘创建了一个vg_cs的vg组，和一个lv_cs的lvm卷，并挂载到/ cs 下，创建了一个testfile的临时文件，其中内容为1到10万的连续数字。

三、 故障模拟：

这里使用dd方式抹掉了1KB的数据，导致lvm全体信息丢失。

dd后lv，vg，pv信息都看不到了：

特别提示：

LVM标签，在磁盘的第二个扇区位置，占512字节空间。紧随其后的是lvm原数据（metadata）。

四、 恢复过程：

直接使用 vgcfgrestore 来恢复盘头的lvm信息，失败：

提示中，很明显，显示原来sdb设备的uuid找不到了，无法恢复，提示vg _cs 的一个pv被标记为丢失，恢复失败。

这时候需要考虑恢复的必要条件：

1、 肯定是盘面上的大部分数据存在

2、 恢复lvm信息，让操作系统能识别到这块盘

所以现在需要想办法实现第二点，即恢复lvm信息。思路是，创建新的pv，用新的pv信息代替老的，再恢复lvm信息，这种方式是否能恢复不确定，我们只是尝试，如果能恢复出lvm信息让系统识别，即有很大希望恢复数据了。

重建pv，发现失败，提示sdb已挂载？

再看下挂载点信息：

没有挂载

尝试强制重建：

也没有起到作用。

继续排查。

发现lv仍以块设备形式存在，这种情况在主机突然丢失物理盘导致，重启应该就不会有这个问题了。此时，使用逻辑卷管理dm set up强制移除v g_cs-lv_cs 。

移除完成后，再创建卷。

特别提示：

1、上面使用了原磁盘sdb的uuid来重新创建sdb的pv信息， pvcreate命令，只是会重写（overwrite）sdb盘面上lvm的元数据，而不会影响sdb上存在的数据区域！！

2、测试模式（- -test ），只会验证性检查这步操作是否会成功，而不会直接更新该盘的lvm元数据信息，是一种实际操作前的保护机制。这步验证没问题，我们继续操作。

好了，再尝试恢复：

恢复成功！心情激动！

信息也都回来了。

激活，挂载吧！

数据都在 恢复成功！

五、 总结：

1、 虽然盘的数据不完整了，不要轻易重新格式化；

2、 想一切办法去恢复盘头上的lvm信息

3、 如果盘头信息丢失不多，比如几个扇区大小的数据，因超级块系统本身会备份，所以这时用文件系统的修复（xfs_repair 或者e2fsck 等）或者直接用vgcfgrestore 一般可以解决问题的。

场景2：逻辑卷池中某个LUN盘无法识别

一、 故障描述：

在vg组中，存在多块LUN盘，其中一块LUN盘因某个原因，导致系统无法再识别到，需要利用剩余的LUN盘来恢复数据。这种情况下，因整个vg组不完整，导致vg或者lv无法挂载、识别、读写。

需要强调的是，丢失的LUN盘上要么是没有数据，或者丢失少量数据。如果上面丢失的数据较多，且是关键性的数据，那么这个问题，将转变为物理磁盘介质的数据恢复，需要转由硬件设备厂商或其他数据恢复专家来解决。

二、 测试方式：

初始化环境，使用一块盘创建了一个 vg_cs 的vg组，和一个l v_cs 的lvm卷，并挂载到/ cs 下，创建了一个testfile的临时文件，其中内容为1到10万的连续数字。

其中vg _cs 中含有sdb和sdc盘。

lv使用默认的顺序读写，故测试数据目前存在在sdb 上，使用：

s trings /dev/sdb | more

可以看到，盘头除了lvm相关的文件系统信息外，后面是文件名和文件内容信息。

三、 故障模拟：

此时我们模拟sdc这块磁盘丢失的情况，方法有两种，一是使用dd方式抹掉所有盘数据；二是从存储端拿掉sdc 盘的映射关系。

操作完后，重启主机，可以看到lv中出现unknown状态的卷：

uuid= UMpJuh-6cVh-3Hyc-MrTK-GDwo-TPeC-Wjb4NG 的卷，就是刚才的sdc卷，在/ etc /lvm/backup 中，也可以找到对应的关系。

特别提示：

关于pvs，lvs和vgs中Attr各个字节对应的含义，最准确快速查找的方法是：

man 对应的命令，然后搜索pv_attr 、lv _attr 或者vg _attr ，就有当前版本最准确的解释了。这里为了方便大家快速浏览，三条命令的属性解释见附件一。

四、 恢复过程：

直接使用vgcfgrestore来恢复盘头的lvm信息，失败：

提示中，很明显，显示原来sdb设备的uuid找不到了，无法恢复，提示vg _cs的一个p被标记为丢失，恢复失败。

提示：

如何获取丢失盘的uuid？

1、 执行lvm相关操作后，会如上所示，直接提示出来；

2、 pvscan执行时

3、 lvm的备份信息中，即/ etc/lvm/backup/vg_cs 中也可以找到

这时候要用一个新的空盘来恢复，这里我们已经重新映射一个sdd到主机上，使用这个sdd来重建uuid= UMpJuh-6cVh-3Hyc-MrTK-GDwo-TPeC-Wjb4NG 的pv。

提示成功了，这时vg _cs是完整的了。

验证lvm相关的信息：

这时，lv _cs 处于非激活状态，激活

因为少了一部分数据，所以这时候一定要做文件系统修复：

从修复的过程看，丢失的信息其实还是不少的，sdc上的数据肯定都没有了。

最后挂载，验证：

再看看相关数据，都恢复上了。

五、 总结：

和场景1类似，如果要恢复一个lvm上剩余的数据，也需要给操作系统一个完整的lvm信息，这个才能作为一个完整的文件系统进行挂载，虽然此时数据已经不完整。