正文如下：
LVM是 Logical Volume Manager(逻辑卷管理)的简写。LVM将一个或多个硬盘的分区在逻辑上集合，相当于一个大硬盘来使用，当硬盘的空间不够使用的时候，可以继续将其它的硬盘的分区加入其中，这样可以实现磁盘空间的动态管理，相对于普通的磁盘分区有很大的灵活性。（ 详见附件 红帽官网 LOGICAL VOLUME MANAGER ADMINISTRATION （RedHat 7 ） ）
场景3：LV信息被误删除
一、 故障描述：
lv（logical volume ）信息可能因管理员误操作，导致被误删除了，此时数据依旧完整。
二、 测试方式：
初始化环境，使用一块盘创建了一个 vg_cs 的vg组，和一个lv_cs 的lvm卷，并挂载到/cs 下，创建了一个testfile的临时文件，其中内容为1到10万的连续数字。
三、 故障模拟：
此时我们手工删除lv _cs ，以模拟误删除场景。
四、 恢复过程：
首先还是直接使用vgcfgrestore来恢复尝试恢复：
提示中，显示每个逻辑卷块设备的seqno序号增加了1，与之前不一致了。
使用vgchange来激活vg _cs 里的lv，提示没有可以激活的对象。同时，lvs信息里也没有lv _cs 。说明目前的恢复是失败的。
从前面的seqno序号提示错，去检查下lvm最后一次备份信息：
从文件的description部分，文件在执行lvremove后被创建，所以这个最新的，存在在/ etc/lvm/backup 目录下的文件，里面已经没有lv_ cs 的卷信息了！
从这里不难发现，每次我们对lvm操作，操作系统都会自动的做一次备份，这在归档目录，也就是/ etc/lvm/archive 中，可以确认的到：
关于archive和backup的保留策略，可以在lvm.conf 中配置，例如：
到这里已经很明确了，我们要利用lvremove之前的归档文件去恢复，所以即archive目录下的最后一个文件进行恢复：
激活lv后，可看到数据恢复了。这里因为数据本身没有改动，所以也没做文件系统的检查或恢复了。不过建议还是做一下比较好。
五、总结：
/ etc/lvm/ back up 文件始终是最新的lvm备份文件，每次lvm相关的操作都会将这个文件移到 archive 下，并再生成最新的backup文件。
场景4：云平台磁盘迁移中磁盘缩容
一、故障描述：
云平台在做磁盘迁移（retype）过程中，可能会因云平台存储驱动等参数配置问题，导致在初始创建磁盘时，比实际需求略大。如建1000G磁盘，实际创建了1000.11G的磁盘大小。
这可能会造成后续retype过程中，新建的磁盘（标准1000G）略小于原磁盘大小（1000.11G） 。迁移完后，文件系统挂载时，校验扇区个数时少于lvm配置文件中的扇区数，导致挂载失败，文件系统打开失败。
这种情况极少见，恢复难度五颗星！
二、故障模拟环境 ：
模拟存储超分，进行虚机的数据盘迁移。在使用云平台retype命令迁移结束后，发现文件系统出现异常，执行lvm相关命令均出现如下提示：
从提示中可以看到，vdb这块磁盘现在的扇区个数（209715200 ）小于lvm信息中pv记录的扇区数（2097379328），加载/dev/vdb失败。
此时，操作系统层面，能看到vdb，但找不到对应的vg和lv。
三、恢复过程：
接下来是个较为复杂的恢复过程......
从操作系统的提示，问该磁盘是否进行过resize（ Was device resized? ），也验证了磁盘大小发生了改变。
先看下backup中lvm相关信息：
原LVM信息中，/dev/vdb扇区数：209737328
原厂提供的支持过程：
首先使用pvcreate尝试恢复lvm信息
特别提示：
从上图中可以看到，尝试重新初始化vdb这个pv，但仍失败，后我们分析，这里存在了lvm数据恢复的另一个因素，即在初始化设备时，会校验底层pv的扇区大小，来保证数据的一致性！
继续后面的步骤，尝试用lvm备份文件恢复lvm盘头信息，提示mda信息不一致
lv激活失败，lv信息未正常识别到。
此时，有一些地方介绍使用pvresize --setphysicalvolumesize，这将可能导致盘上数据丢失，谨慎操作！！
随后操作系统原厂又多次使用pvcreate搭配不同的参数、lvscan、vgscan等操作来尝试恢复，但仍因扇区数不一致，没法正常初始化lv_app设备。
再尝试用archive下的备份文件来恢复lvm信息，虽然vg和lv均能看到，但无法激活。
最终献出pvresize操作：
执行完后，lv_app仍无法激活， 推测pv上数据已丢失 。vg信息中显示没有已分配的空间：
从 <附件二 lvm扩容后逻辑卷为suspended状态无法挂载 > 案例中，pvresize后重新将pv再扩容到vg池中，pv等于是做了清空处理。
最终结论：“系统层面是无法恢复了。
事后尝试恢复数据：
在经过应用恢复数据，恢复了业务后，我们利用保留的“事故现场”再尝试恢复数据。
从上述恢复过程来看，操作系统一直在恢复出lvm信息后，仍会不断检查pv的扇区数，如果不一致，则无法激活对应的lvm。
所以，我们的思路是使用一个大于原先扇区数的新盘来恢复出数据。
第一步，我们挂载新的vdd块设备，其扇区数比原先的PV（2897379328）还要多。
第二步，我们使用dd命令，将vdb（无法打开的块设备）上数据完整的拷贝到vdd上。
第三步，此时，直接使用vdb的uuid号，来恢复lvm信息到vdd上，会提示uuid号重复已存在，且vg_app信息存在两个相同的vg信息。
此时，我们用了一招 “偷梁换柱”：
用vgimportclone 命令，创建vg_app 的快照 ：
将原vdb上的vg信息，重命名为vg_app_snapshot了。消除了两个相同的vg_app。
紧接着，尝试激活vg_app_snapshot，但可想而知，vdb小于预期（2897379328）,所以激活失败。
此时vgcfgrestore直接来恢复vg_app，恢复前确认/etc/lvm/backup/vg_app中的PV信息（uuid和块设备名）是否和vdd的保持一致。
此时新划的vdd上的lvm信息，包括PV、VG、LV信息均可用！
文件系统激活、挂载均正常，数据可用！
恢复成功
四、总结
本次恢复过程，我们发现，除了满足：
vdd磁盘上lvm信息正确，完整；
vdd上数据可用；
以外，还需要满足：
vdd磁盘上可用扇区数大于或等于lvm信息中的扇区数，校验通过！
当然同一主机上的vg信息是唯一的，不可重复！
VG Attr
LV Attr（第 2 - 6 字段）
PV Attr
附件二：
红帽官网 LOGICAL VOLUME MANAGER ADMINISTRATION （RedHat 7 ）
lvm扩容后逻辑卷为suspended状态无法挂载
https://developer.aliyun.com/ask/250921?spm=a2c6h.13524658&;
转文至此。
以下是个人微信公众号，欢迎关注：
