企业官网建设流程全解析

记一次 Linux PV Missing 故障

做运维这些年，最怕的就是早上一来看到告警群里有“文件系统只读”或者“挂载点消失”的消息。比这更让人心里一紧的，是登录服务器执行vgdisplay时看到那行刺眼的提示——PV 状态变成了 unknown device，或者干脆在pvscan里看到一个孤零零的 missing 标记。

LVM 这套逻辑卷体系平时用着挺省心，空间不够了就扩一扩，磁盘要换了就 pvmove 挪一下。可一旦底层 PV 出问题，整个 VG 就像断了线的木偶，LV 挂载不上，业务直接停摆。这类故障的排查过程往往很绕，因为表面上是“卷组挂了”，但根因可能在盘、在驱动、在多路径、甚至在系统启动顺序上。这次我就把最近一次完整的排查过程记录下来，从现象到原理，再到一步步怎么救回来，希望能给遇到同类问题的朋友一个参照。

1. 故障现象与最初的判断

1.1 挂载点消失，系统日志先给了线索

这次出问题的是一台跑内部应用的物理服务器，系统是常见的发行版，根盘和数据盘做了分离。某天早上例行巡检的时候发现，挂在 /data 下的逻辑卷不见了，df -h里已经没有这个挂载点。第一反应是文件系统没挂上，但尝试mount -a之后没有任何效果，反而提示找不到对应的设备路径。

此时不能急着重启，更不能直接对 LVM 做修复动作，先按顺序收集现场。我依次执行了lsblk、fdisk -l、dmesg | tail -50，重点关注存储相关的报错。dmesg里能看到一些 SCSI 链路重连的日志，有几条提示是“target 无法访问”这类信息。这个时候心里大概有了底：物理盘大概率还在，但系统启动时没有成功识别，或者识别顺序发生了变化，导致 LVM 在激活卷组时找不到预期的 PV 设备。

1.2 pvscan 和 vgdisplay 暴露了问题核心

接下来看 LVM 层面的状态，命令输出非常直接：

pvscan

输出中出现了一个很不寻常的条目：

PV unknown device VG data_vg lvm2 [1.82 TiB / 0 free]

这里出现的 “unknown device” 就是整个故障的核心信号。它的含义是：data_vg这个卷组在元数据里记录了一个 PV，但当前系统里找不到任何设备能够匹配这个 PV 的 UUID。换句话说，LVM 知道有这么一块盘，但盘不在系统视界内。

再看vgdisplay data_vg，状态显示为不活动，部分 LV 处于 inactive 状态。这个时候已经可以确认：这不是文件系统损坏，而是整个 VG 因为底层 PV 缺失而被 LVM 挂起。正常情况下，只要有一个 PV 消失，VG 就无法正常激活所有 LV，这是 LVM 的一种安全机制——宁可不挂载，也不让你拿着不完整的卷组去读写，避免数据进一步损坏。

2. PV Missing 到底是怎么发生的

2.1 用“户口登记”来理解 LVM 的 PV 机制

要说清楚 PV missing 的本质，得先把 LVM 的几层概念理一理。可以把 PV 理解成一块有“户口”的物理盘，VG 是行政区，LV 是实际分配给用户使用的房子。LVM 的元数据就相当于户口档案，这个档案既写在 PV 的头部区域，也会同步到 /etc/lvm/backup/ 下面。

系统启动时，LVM 通过扫描所有可见设备，读取设备头部区域的元数据，与 VG 里记录的 PV UUID 一一比对。只有所有 PV 都找到对应设备，VG 才能正常激活。当某个 PV 对应的物理设备不可见，或者设备头部元数据无法识读时，LVM 就把它标记为 unknown device，在界面层就表现为 missing。

这里有个容易混淆的点：missing 不代表物理盘一定坏了。很多时候盘还在机器里，但系统没能正确枚举到它；也有时候盘被换了槽位，驱动加载顺序变了，导致内核看到的设备名变了，而 LVM 记录的还是旧设备路径。这种“设备路径漂移”是 PV missing 最常见的原因之一。

2.2 触发 PV Missing 的几种典型场景

排查这类故障，先判断属于哪一类触发场景，能省下大量时间。我整理了几个常见场景：

• 异常断电重启：系统非正常关机后，某些外接盘柜或本地盘的控制卡初始化慢，导致系统枚举设备顺序变化。原来 /dev/sdb 的盘重启后变成了 /dev/sdc，PV UUID 没变，但路径对不上。
• 磁盘拔插或更换槽位：维护时把数据盘拔下来再插回去，插到了别的槽位，或者经过 RAID 卡重新识别后盘序变化。
• 多路径软件未正常加载：使用存储阵列的场景下，如果 multipathd 没起来，或者配置文件里的 wwid 别名没生效，LVM 会看到多个底层设备路径，却找不到映射后的多路径设备。
• 虚拟化环境磁盘热拔插异常：虚拟机里动态卸载再挂载磁盘，如果操作系统没有重新扫描总线，PV 对应的虚拟磁盘设备就不出现。
• 磁盘克隆或迁移后 UUID 冲突：给系统做镜像、克隆之后，新盘和旧盘的 PV UUID 一样，插入同一台机器会导致认盘混乱。

判断场景的意义在于：如果只是设备路径漂移，让系统重新认到盘就能恢复；如果是磁盘永久损坏，就要走另一条路，把缺失的 PV 从 VG 里移除，但那一步操作要非常谨慎。

3. 恢复实操：从确认盘到重新激活卷组

3.1 先确认底层设备是否真的不可见

在动 LVM 之前，第一步永远是确认物理设备的状态。lvm 工具显示 unknown device，不代表底层盘一定消失了。执行以下命令逐个确认：

lsblk fdisk -l cat /proc/partitions ls /dev/sd*

这次排查时，lsblk里能看到一块没有分区的 2TB 盘，设备名是 /dev/sdb，但没有任何挂载信息。fdisk -l显示这块盘上没有有效分区表——这其实是个正常现象，因为 LVM PV 不一定非要建立在分区上，可以直接把整块盘作为 PV。

接着用 LVM 自己的角度再看一眼：

pvs -o +uuid pvdisplay /dev/sdb

这里有一个重要操作：把当前扫描到的物理设备与 VG 元数据记录的 PV UUID 进行比对。pvdisplay /dev/sdb会显示这块盘的 PV UUID，如果它和pvs里 unknown device 对应的 UUID 一致，那就说明盘其实没丢，只是 LVM 没有把设备和 PV 记录对应起来。

这次比对结果正是如此，/dev/sdb 的 PV UUID 和 unknown device 的 UUID 完全一样。那么问题就变成了：为什么扫描到了设备，VG 还显示 unknown？答案通常是系统启动时 LVM 扫描的顺序问题，或者是内核识别设备的时间点晚于 LVM 激活卷组的时间点。

3.2 让内核重新认识设备

确认盘在之后，需要让 LVM 重新读取设备状态。最直接的方式是触发一次设备扫描。常规做法是执行：

vgscan vgchange -ay

vgscan 会重新扫描所有可见设备并重建 LVM 缓存；vgchange -ay 则尝试激活所有卷组。如果设备状态正常，这两条命令通常就能解决问题。

但这次情况和常规不太一样。执行vgchange -ay时提示卷组无法激活，原因仍然指向 PV missing。这说明 LVM 的缓存里对设备状态的记录没有刷新，或者内核层面还没把这个设备真正“挂”到 LVM 可用的状态。

这时候不能蛮干，需要先让内核重新识别设备。对于 SCSI 设备，可以通过触发总线重新扫描来让内核再次枚举设备：

echo "- - -" > /sys/class/scsi_host/host0/scan

如果有多块 HBA 卡，需要把 host0 换成对应的 host 编号。也可以用现成的脚本工具，比如某些发行版自带rescan-scsi-bus.sh，或者安装 sg3_utils 工具包后执行sg_scan配合重新扫描。扫描之后再执行partprobe让内核重新读取分区表：

partprobe /dev/sdb

对于虚拟化环境，还可以通过将设备从内核中移除再重新加入来强制识别。操作路径是往 /sys/block/sdb/device/delete 写入 1，然后重新扫描总线。这个操作有风险，如果设备名对应错了，会把系统盘也摘掉，所以执行之前必须再三确认 /dev/sdb 对应的是数据盘。

3.3 关键一步：恢复 LVM 对设备的信任

重新扫描之后，再次执行pvscan，如果这时候 unknown device 不再出现，而是正常显示为 /dev/sdb 对应的 PV，那么故障已经完成大半。接下来做一次完整的状态确认：

vgscan vgchange -ay data_vg

这次vgchange -ay没有任何报错，VG 成功激活。之后执行mount -a恢复挂载，业务恢复正常。到这一步，一次典型的因设备识别顺序变化导致的 PV missing 就算处理完了。

但问题不能到这就结束。后续要做的两件事同样重要：一是检查 LVM 配置文件，确保下次重启不会再犯；二是备份当前的 LVM 元数据，让后续变更留个底。

3.4 三个版本做法，按风险等级一次说清

上面的处理属于“设备还在、只是识别顺序乱了”的场景。但 PV missing 还有两种更麻烦的情况，需要分别处理：

场景A：设备永久丢失，数据在别的 PV 上有副本或可容忍丢失。

执行vgreduce --removemissing data_vg，把缺失的 PV 从卷组里移除。这个操作的本质是让 VG 接受“缺少一块盘”的现实，并移除元数据里对应的 PV 记录。但要注意，如果被移除的 PV 上存在没有镜像的 LV 数据段，数据就真的找不回来了。所以执行前一定要三思，建议先做vgcfgbackup备份元数据。

场景B：设备回来了，但 PV UUID 对不上。

常见于磁盘克隆、阵列替换后，新盘的 UUID 和旧的不一致。此时可以用pvchange -u /dev/sdb给新盘重新生成一个 UUID，尽量让它接近原记录。但更稳妥的做法是：先用vgextend把新盘加入 VG，再用pvmove把数据从旧 PV 上迁移走，最后vgreduce移除旧 PV。整个过程不丢数据，适合生产环境。

场景C：VG 元数据本身损坏或不同步。

用pvck检查 PV 头部的元数据，必要时用备份的 /etc/lvm/backup/ 目录里的备份文件恢复。这个场景更少见，但一旦遇上就比较棘手，需要逐一校验备份文件的完整性和对应关系。

4. 常见问题与排查技巧实录

4.1 五分钟速查表

4.2 排查过程中几个容易踩的坑

第一个坑是一上来就执行vgreduce --removemissing。有些教程会把这条命令当作通用解法，但这是破坏性操作。我之前就见过有人因为图省事直接执行，结果某块 PV 上的数据段没有副本，导致整个 LV 文件系统损坏。在确认数据可丢失之前，这条命令碰都不要碰。

第二个坑是忽略了 /etc/lvm/lvm.conf 里 filter 配置的影响。如果 filter 规则写死了一些设备路径，比如filter = [ "a|/dev/sd.*|", "r|/dev/sdb|" ]，那么即使盘插在那里，LVM 也会视而不见。处理这类问题时，一定要先检查 filter 规则，必要时临时去掉过滤规则再扫描。

第三个坑是没有在修复后同步 /etc/fstab。这次的故障表面上看是 LVM 的问题，但根本原因是设备路径漂移。如果在 /etc/fstab 里写的是/dev/sdb1这类设备路径，即使卷组激活了，挂载时也可能因路径对不上而失败。建议挂载一律用 UUID 或 LVM 的卷组逻辑路径，比如/dev/mapper/data_vg-data_lv。

4.3 工具选型与配置要点

处理 LVM 相关故障，最常用的一个工具组合是lvm2自带的 pvs/vgs/lvs 三件套，配合pvck做低层检查。有些发行版默认不装 lvm2，需要单独安装：

yum install -y lvm2 apt install -y lvm2

另一个容易被忽略的工具是vgcfgbackup。它把 LVM 元数据备份到 /etc/lvm/backup/ 目录下，恢复时配合vgcfgrestore使用。每次对卷组做变更前，比如添加、移除 PV，都建议先执行一次备份。它不占用额外空间，却能提供最直接的回滚手段。

如果环境里用了多路径，还需要确保 multipath 工具正常加载，并检查 multipath.conf 里的 alias 配置是否稳定。多路径环境下，LVM 应该通过 /dev/mapper/ 下的多路径设备名来识别 PV，而不是物理盘符。

5. 故障后续：让系统别再重蹈覆辙

5.1 修改启动顺序与过滤规则

这次故障的根因是设备识别顺序不稳定，修复只解决了当下问题，如果不做加固，下次重启可能还会再来一次。第一道防线是在 /etc/lvm/lvm.conf 里显式声明 PV 设备路径，或者直接按 PV UUID 过滤。比如把数据盘的 wwid 记录到配置文件里，让 LVM 只认这个标识对应的设备。

如果盘符会随机变化，更推荐在 /etc/fstab 里改用 LVM 逻辑路径，同时设置x-systemd.device-timeout=0或nofail选项，避免系统启动时因为找不到设备而卡在挂载阶段。

5.2 日常监控与告警

LVM 层面的异常最好在第一时间被发现，很多故障如果早十分钟处理，就能避免业务长时间中断。运维脚本里可以加一段定期检查：

#!/bin/bash pvscan | grep -i "unknown" if [ $? -eq 0 ]; then echo "LVM PV missing detected, please check immediately" fi

也可以用监控系统定时执行vgs -o vg_name,vg_attr检查卷组状态，p 状态表示 partial，说明有 PV 缺失，这时候就要触发告警。

5.3 从一次故障中总结的实操习惯

经过这次故障，我把 LVM 相关操作的习惯整理成了几条固定原则：

• 任何修改卷组的操作之前，先vgcfgbackup，这是底线。
• 看到 unknown device 时，第一件事永远是查硬件设备，而不是查 LVM 配置。
• 修复结束后，务必同步检查 /etc/fstab 和 lvm.conf 过滤规则。
• 在文档里记录每块物理盘对应的 PV UUID，一旦出问题可以快速比对。

5.4 最后想说的话

说句实在话，LVM 的 PV missing 故障本身并不复杂，真正考验人的是判断“盘到底还在不在”。盘在，走重新扫描恢复；盘不在，走数据容灾恢复；盘在但 UUID 变了，走数据迁移或 UUID 重写。把这三条路想清楚了，遇到任何 missing 都能有条不紊地处理。

这次故障让我印象最深的一个细节是：一开始dmesg里其实早就给出了提示，但被我一心急就直接跳到 LVM 层面去了。后来复盘发现，如果第一时间顺着 SCSI 重连的日志往下查，可能十分钟就能定位到设备枚举顺序的问题。这也算是一次教训——排查存储类故障，永远先从最底层、最原始的信息看起，而不是被上层的表象牵着走。