一次Linux LVM VG丢失完整找回过程记录

某客户的一台PC服务器连接了一台HP EVA 的FC
SAN存储，划了一个6T的LUN分作一个单独的VG使用，在某一次异常掉电之后，发现该VG完全丢失，使用vgs/pvs/lvs命令均无法找到此VG及PV、LV，但在/dev下能看到SAN存储的两条路径/dev/sdc和/dev/sdb以及聚合出来的多路径盘/dev/mpathc。

由于LVM
VG已经丢失，数据自然是暂时不可用的，从存储管理端看到存储并无任何报错，于是怀疑是由于系统层面引发的该故障。由于LUN比较大，数据有近6T的大小，考虑到简单的一次异常关机应该不至于会导致数据全部丢失，考虑到可能是由于存储在PV上的VG元数据丢失造成的。后面从/etc/lvm/backup下面的vg信息备份文件里面找到了PV的UUID，再使用指定原PV
UUID及restorefile的方式重新pvcreate，再执行vgcfgrestore，成功找到数据，验证了以上的猜测。需要说明的是，类似这种对于VG/PV的底层操作，都可能会造成数据的永久丢失，除非是到万不得已的情况下，否则一定不要轻易在生产环境尝试此类危险操作。

下面就来模拟一下故障修复的全过程，模拟方法及环境是，使用虚拟机运行SLES
11，添加一块2GB大小的虚拟硬盘，将该虚拟硬盘创建为单独的VG，划分LV之后，格式化LV并挂载，在该LV上写入一些测试文件。再卸载LV，卸载VG，使用pvremove强制把该虚拟硬盘PV的uuid清除掉，并再次pvcreate该虚拟硬盘以重新分配一个PV
UUID，最后再从自动备份的/etc/lvm/backup/下面的文件恢复到原来PV UUID进而恢复原来的所有VG信息。

 LVM VG丢失完整找回过程记录" title="一次Linux LVM VG丢失完整找回过程记录">

开始操作之前原有的VG/PV/LV信息

接下来将新加入的2GB大小的虚拟硬盘创建成PV/VG，并划分一个500M的LV，格式化成EXT3。

Sles11 # pvcreate /dev/sdb

Sles11 # vgcreate datavg /dev/sdb

Sles11 # lvcreate datavg –n lv01 –L 500M  
  // 创建一个500M大小名称为lv01的LV

Sles11 # mkfs.ext3 /dev/mapper/datavg-lv01  
// 格式化为ext3

 LVM VG丢失完整找回过程记录" title="一次Linux LVM VG丢失完整找回过程记录">

上面的操作完成之后，再看一下当前的VG/PV/LV信息。

 

LVM VG丢失完整找回过程记录" title="一次Linux LVM VG丢失完整找回过程记录">

现在把该LV挂载起来，往里面写入一两个文件，并记录下来这些文件的大小（以便后面验证恢复回来的VG是否会丢失数据）。

 LVM VG丢失完整找回过程记录" title="一次Linux LVM VG丢失完整找回过程记录">

接下面开始模拟把该PV的UUID重建。

Sles11 # pvdisplay /dev/sdb  
  // 查看当前的PV UUID，记录下面备用

Sles11 # umount /dev/mapper/datavg-lv01  
 // umount该LV以卸载VG

Sles11 # vgchange –an datavg  
   // 关闭该VG

Sles11 # pvremove –ff /dev/sdb  
  // 清除掉该PV的LVM标签，让它不再是PV，即抹掉PV UUID

 

LVM VG丢失完整找回过程记录" title="一次Linux LVM VG丢失完整找回过程记录">

此时，环境全部模拟完成，再次执行vgs&&pvs&&lvs已经完全看不到datavg和/dev/sdb的任何信息。现在整个系统的状态就跟开始提到的客户发生的故障完全一致。为了把故障搞得再大再狠一点，我们重新把/dev/sdb手动执行一次pvcreate，重新分配一个新的UUID给它。

 LVM VG丢失完整找回过程记录" title="一次Linux LVM VG丢失完整找回过程记录">

注意看到现在的/dev/sdb的PV
UUID已经跟之前的UUID完全不一样了，现在我们就来恢复原来的VG信息及所有的文件信息。

在开始之前，需要提一下，Linux的LVM会默认存储用户对PV/VG/LV的每一步操作，并自动把当前的VG的信息备份到一个文件里面，位置是/etc/lvm/backup/VG名。这个文件里面记录的东西大概跟vgdisplay/pvdisplay/lvdisplay输出的信息一致，里面也包括了对于恢复VG信息至关重要的PV
UUID。这个文件记录的信息大概就相当于整个VG的元数据，这个文件非常重要，我们就是通过这个文件来恢复整个VG的信息的，下面是这个文件的不完整截图。

 LVM VG丢失完整找回过程记录" title="一次Linux LVM VG丢失完整找回过程记录">

下面开始执行恢复。

Sles11 # pvcreate /dev/sdb -u
X4xYDe-VSiw-Gzh3-Ih78-dC08-xBKF-tGWc5s --restorefile
/etc/lvm/backup/datavg

// 使用原来的PV UUID来创建PV，并使用自动备份的文件来恢复信息

Sles11 # vgcfgrestore datavg  
   // 恢复datavg的vg信息

Sles11 # vgs && pvs && lvs

LVM VG丢失完整找回过程记录" title="一次Linux LVM VG丢失完整找回过程记录">

 

可以看到，执行完以上命令之后，PV及VG/LV都恢复回来了。现在来验证一下文件是不是都还在。

Sles11 # vgchange –ay datavg  
  // 激活该vg

挂载上该LV之后，再查看里面的文件信息，发现跟之前的完全一样，验证成功。

 LVM VG丢失完整找回过程记录" title="一次Linux LVM VG丢失完整找回过程记录">

通过该案例，可以了解到，Linux对于LVM的操作是提供了一些灾难恢复的选项的，而通常情况下我们对PV/VG/LV的操作，除了格式化LV外，基本上都不会破坏实际存储的数据，只是对LVM的元数据进行操作。而此例实质也就是恢复了LVM的元数据而已。

最后再次提醒，在生产环境上执行此类VG的底层命令一定要谨慎再谨慎，毕竟数据无价，要养成经常备份数据的习惯。