多块磁盘配置lvm卷 不含vg卷的某块磁盘损坏解决

解析

Linux 的 LVM 会默认存储用户对 PV/VG/LV 的每一步操作,并自动把当前的 VG 的信息备份到一个文件里面,位置是 /etc/lvm/backup/VG 名或者 /etc/lvm/archive/VG 名。这个文件里面记录的东西大概跟 vgdisplay/pvdisplay/lvdisplay 输出的信息一致,里面也包括了对于恢复 VG 信息至关重要的 PV UUID。

适用场景:

误操作、磁盘异常掉电等原因可能会造成硬盘的逻辑损坏,当LVM中某块硬盘出现异常时,会导致部分逻辑卷或整个卷组无法访问的情况。我们查看pv时会发现提示unknow device,并提示“Couldn’t find device with uuid xxx”。问题如图,本文介绍了LVM中某块硬盘损坏的灾难修复,来尽可能恢复灾难所造成的数据损失。

一. 具体现象

模拟坏境:两块磁盘配置 lvm 挂载于home目录,模拟其中一块磁盘损坏(手动卸载其中一块磁盘)

https://github.com/zznn-cloud/zznn-cloud-blog-images/raw/main/Qexo/24/4/image_01d0781150239f60d611e745039163f0.png

挂载目录写入文件测试恢复 能否恢复数据

https://github.com/zznn-cloud/zznn-cloud-blog-images/raw/main/Qexo/24/4/image_d66d4886fa622e78c8eb0e4a953bc95a.png

现象此时有一块pv处于unknow状态 重启系统后现象如下

  • lsblk 查看没有看到 /dev/mapper 开头的lvm卷
  • pvs 查看有一块磁盘 pv 处于 unknow 状态 并且显示:WARNING: Couldn’t find device with uuid FCda1V-EwWN-qtfc-6SZ4-Vu1e-v8FG-XUCr5H 找不到这个uuid的设备
  • mount 挂载显示找不到设备

https://github.com/zznn-cloud/zznn-cloud-blog-images/raw/main/Qexo/24/4/image_2f4b8b5f102e1cf6be27e0f7225fc7a8.png

二. 解决

  1. 服务器新添加一块磁盘 磁盘的大小和 损坏磁盘的大小一致 此次新添加磁盘为 /dev/sdd

  2. 使用pvs定位损坏磁盘uuid: 8Acrc0-21LJ-yWfm-f7gb-2uvf-ogLu-cG6OIT

    https://github.com/zznn-cloud/zznn-cloud-blog-images/raw/main/Qexo/24/4/image_7ad156f3d7d7bb8786b4b9794428c366.png

  3. 使用原来的PV UUID来创建PV,并使用lvm配置备份文件来恢复信息

    1
    2
    3
    4
    5
    6
    # 查看pv返回损坏磁盘uuid: 8Acrc0-21LJ-yWfm-f7gb-2uvf-ogLu-cG6OIT
    pvs
    # 使用原来的PV UUID来创建PV,并使用lvm配置备份文件来恢复信息(本文使用)
    pvcreate --uuid 8Acrc0-21LJ-yWfm-f7gb-2uvf-ogLu-cG6OIT --restorefile /etc/lvm/backup/vg_mf /dev/sdd
    # 或使用类似如下命令
    pvcreate /dev/vdc -u qaTzJn-Hdgc-aeC5-EUT0-H1l1-tPiA-rYXnDx --restorefile /etc/lvm/archive/vgtest_00002-645033136.vg
  4. 我们可以看到sdc已经成功替换为了sdd

    https://github.com/zznn-cloud/zznn-cloud-blog-images/raw/main/Qexo/24/4/image_9029ced509c4251026a34bf3d3959213.png

  5. 如果替换后的/dev/sdd 的attr为a-m 表示/dev/sdd为missing状态 则需要执行下方命令恢复

    1
    2
    3
    4
    # 替换后的/dev/sdd 的attr为a-m 表示/dev/sdd为missing状态 则需要执行下方命令恢复(本文使用)
    vgextend --restoremissing vg_mf /dev/sdd
    # 或使用类似如下命令方式
    vgcfgrestore -f archive/vgtest_00002-645033136.vg vgtest
  6. 确认硬盘没有在 missing 状态后,对卷组进行恢复,提示恢复vg,没有报错,使用lvscan发现当前lv状态为inactive。

    1
    2
    3
    4
    # 刷新
    lvscan
    # 恢复卷组信息
    vgcfgrestore -f /etc/lvm/backup/vg_mf vg_mf

    https://github.com/zznn-cloud/zznn-cloud-blog-images/raw/main/Qexo/24/4/image_dec1593e4a081755a2714700aa9fc7f9.png

    https://github.com/zznn-cloud/zznn-cloud-blog-images/raw/main/Qexo/24/4/image_f5fbb85873ba0a7afb2d618093af9743.png

  7. 激活vg,再次查看

    1
    2
    3
    4
    # 刷新
    lvscan
    # 激活vg
    vgchange -ay vg_mf

    此时再次使用 lvscan 查看 lvm 卷状态变为 active

    https://github.com/zznn-cloud/zznn-cloud-blog-images/raw/main/Qexo/24/4/image_92c783e15b2248b4ca139d58f27f9000.png

  8. 最后重新挂载

    1
    2
    3
    4
    # 查看磁盘uuid
    blkid
    # 挂载lvm卷
    mount /dev/mapper/vg_mf-lv_mf /home

    https://github.com/zznn-cloud/zznn-cloud-blog-images/raw/main/Qexo/24/4/image_11474a9f9fdc89f0de5d179adac186d2.png

    验证数据是否恢复

    https://github.com/zznn-cloud/zznn-cloud-blog-images/raw/main/Qexo/24/4/image_e38c176548f7b5581090fcad7b034dfe.png

    但是这种方式存在一个bug 有时候重启lsblk 看不到lvm卷信息 需要重新激活vg卷 挂载.。

此时恢复成功。

本文参考