清早刚到工位，告警群就炸了：业务库连不上了。后台一查，/data 目录还在，但里面空荡荡的，/dev/mapper/vgdata-lvdata 这个逻辑卷设备直接消失了。再敲lvdisplay，系统甩出一句 "one or more volumes unknown"，pvs里有一块 PV 的状态是 missing。这种 linux pv missing 故障，我这几年前前后后遇到过好几回，处理多了就形成一个习惯性判断：先不慌，看看底层设备还在不在，大概率数据根本没丢，只是 LVM 暂时把这块物理卷"弄丢"了。
这篇就把整个排查和恢复过程掰开讲一遍。里面涉及的命令、判断逻辑、踩过的坑，都是可以直接拿去用的。适合刚接触 LVM 的运维新手，也适合遇到同样故障想确认步骤的同行。
1. 故障现象：重启后业务目录变成了空目录
1.1 现场还原
先交代一下环境。这是一台负责数据业务的 Linux 服务器，存储规划很常见：系统盘独立，数据盘用 LVM 管理。数据盘建了一个卷组 vgdata，里面做一个逻辑卷 lvdata，格式化成文件系统后挂载到 /data。故障导火索是前一天晚上机房有一次计划内重启，重启后系统是起来了，但业务起不来，应用日志里全是数据库连接失败。
排查的时候发现 /data 挂载点还在，可里面的文件一个都看不到。这个瞬间最容易让人慌，第一反应基本是"盘坏了"或者"数据被清了"。但其实往下查一层就会发现，问题根本不是文件系统层面的，而是 /dev/mapper 下面少了 vgdata-lvdata 这个设备。块设备都没了，文件系统自然挂不上，目录在你眼里就是个空壳。
在 /etc/fstab 里如果写的是/dev/mapper/vgdata-lvdata /data ext4 defaults 0 0，系统启动时就会尝试挂载。挂载失败会让启动流程报错，某些发行版会降级成维护模式，或者干脆跳过挂载点，让你看到一台"活着但业务全挂"的机器。
1.2 PV missing 到底意味着什么
LVM 是三层结构：最底层是 PV（物理卷），中间是 VG（卷组），最上层是 LV（逻辑卷）。对用户来说访问的是 LV，但数据最终落在 PV 上。PV 和 LV 之间的映射关系记录在 VG 元数据里，而 VG 元数据又分散保存在每一个 PV 的头部区域，也就是磁盘开头的元数据区。
PV missing 是 LVM 管理层面的一个状态。它表示 VG 元数据里记录了这块物理卷，但当前内核和 LVM 工具都找不到它。找不到的原因有很多，可能是设备没插好、盘符变了、多路径服务没起来、LVM 的 filter 配置把它过滤掉了，甚至只是设备扫描缓存出了问题。
关键点在于：PV missing 不等于数据物理损坏。打个比方，通讯录里存了这个人，但现在打不通电话，不代表人就没了。数据大概率还安静地躺在磁盘上。重点是别在不恰当的操作下把这份"联系"彻底弄断。
1.3 先立几条规矩，避免二次伤害
动手之前，几条规矩先立好：
- 把当前
pvs、vgs、lvs的输出保存到文件，这是第一手现场信息。 - 只读操作优先。所有能不加写操作就不加。
- 不要贸然执行
pvremove、vgremove、lvremove这类破坏性命令。PV missing 状态下，一些老手都会想当然地去"清理"，这一清可能就真把元数据抹了。 - 备份目录先看一眼，
/etc/lvm/backup和/etc/lvm/archive里有没有历史元数据备份，这决定了后面路宽不宽。
2. 第一步排查：用 LVM 自身的命令看清现状
2.1 pvs / vgs / lvs 三件套，先把状态定下来
我的习惯是先跑三连：
pvs vgs lvs三个命令分别对应三层状态。看到pvs输出里有一行设备路径是[unknown]，并且 Attr 那列末尾带了一个m字母，基本就是 missing 状态了。示意输出大概长这样：
# pvs PV VG Fmt Attr PSize PFree /dev/sda2 vgdata lvm2 a-- 100.00g 20.00g [unknown] vgdata lvm2 a-m 200.00g 0Attr 里的m就是 missing。再看vgs，关注两个数字：#PV和#LV。如果你知道这个 VG 原本是两块 PV，现在#PV显示 1，那缺的那块就是它。如果 VG 的 Attr 里出现p这个字母，表示 partial，也就是卷组处于部分 PV 缺失的状态。
接着看lvs。LV 的 Attr 第一个字母是 type，比如线性的l或者 RAID 的r，这块暂时不用太纠结。重要的是 LV 是否处于"不可用"状态。很多时候 PV missing 但 LV 没有直接报 dunno，只要 missing 的那个 PV 上没有该 LV 的 extent，LV 反而还能正常激活。所以下一步要看映射关系。
2.2 lvdisplay -m 看清数据落在哪
这一步特别关键。用lvdisplay -m看 LV 的 extent 映射到哪些 PV 上，比如：
lvdisplay -m /dev/vgdata/lvdata输出里会列出 Logical volume 下面的 Physical volume 段。如果发现这个 LV 的部分 extent 正好落在那块 missing 的 PV 上，那这个 LV 基本就是不可用的。如果 LV 的 extent 全部落在还健康的 PV 上，恭喜，即使缺一块 PV，LV 可能照样能激活，只是 VG 容量变小了。
这个判断直接决定恢复策略。很多人在 PV missing 时恢复不了 LV，就是没先确认这块磁盘上到底有没有数据。搞清楚这个，后面就不会做无用功。
2.3 从系统日志里找异常信号
LVM 层面的状态定下来之后，去系统日志里找线索。我的顺序是：
dmesg | grep -iE 'blk_update_request|I/O error|device offline' journalctl -b | grep -iE 'sda|sdb|ata|scsi'重点关注有没有磁盘 I/O error、device offline、reset 之类的关键字。如果日志里全是这类错误，物理层面出问题的概率大；如果日志干干净净，但 LVM 就是认不到，那多半是配置、路径、多路径或者元数据层面的问题。
这一步做完，心里基本有个判断框架：
- 底层设备可见、LVM 元数据还在 → 刷新缓存、激活 VG 即可。
- 底层设备可见、但 PV 元数据损坏或丢失 → 考虑从存档恢复。
- 底层设备不可见 → 先解决硬件、驱动、多路径问题，再回到 LVM 层处理。
- 完全找不到设备且日志显示磁盘损坏 → 数据恢复优先级最高，不要用常规手段硬来。
3. 第二步排查：底层设备到底还在不在
3.1 块设备级排查：先把 lsblk 跑一遍
LVM 说 PV missing，但到底是真的没了还是没被扫到，必须回到底层块设备这一层确认。
lsblk -f fdisk -l cat /proc/partitionslsblk -f能直接看到块设备上的文件系统类型、UUID 和挂载点。如果发现某个磁盘上有 LVM 相关标记，但设备名和记忆中不一样，大概率是盘符漂移了。比如原来是/dev/sdb，重启后变成/dev/sdc。
盘符漂移这件事在 Linux 上太常见了。内核枚举磁盘的顺序不保证每次一致，尤其有多块同型号硬盘或者多块虚拟磁盘时。这时候不要靠记忆，要用 UUID 或 /dev/disk 下的稳定设备名来确认身份：
ls -l /dev/disk/by-id/ /dev/disk/by-path/ /dev/disk/by-uuid/把输出和 LVM 元数据里的 UUID 对照。LVM 管的是 UUID，不是设备名。只要 UUID 对得上，设备路径变到哪都能找回来。
顺便说一句，如果有条件，硬盘健康状态也可以看一眼。机械盘用smartctl -a /dev/sdX，重点关注 reallocated_sector_ct、pending sectors、health 这一栏。部分 SSD 和虚拟磁盘不支持 SMART，这种情况只能看别的迹象。
3.2 多路径环境是最常见的坑
生产环境里，PV missing 很大比例不是硬盘坏，而是多路径没起来。尤其双控制器、双光纤、双 SAS 的环境，底层同一块盘会被识别成多条路径，比如/dev/sdb和/dev/sdc其实是同一个物理磁盘。正常情况下由 multipathd 聚合成一个/dev/mapper/mpathX。
如果重启后 multipathd 没起来，或者配置被人动过，LVM 就会看到两块独立的裸设备，而 VG 元数据里登记的 PV 是/dev/mapper/mpathX，现在扫描不到这个名字，于是报 missing。检查方法：
systemctl status multipathd multipath -ll cat /etc/multipath.conf如果确实没起来，直接启动服务，然后重新扫描：
systemctl restart multipathd vgscan --cache pvscan vgchange -a y vgdata更多时候问题出在 LVM 的 filter 配置上。/etc/lvm/lvm.conf里 devices 段如果配置了 filter，只允许a|/dev/mapper/mpath.*|而拒绝其他设备，那一旦多路径设备名没恢复，LVM 自然什么都扫不到。这个坑我在 5.2 场景里再细说。
3.3 虚拟化与云环境：别忽略平台侧的操作记录
如果是虚拟机或者云服务器，排查方向要加上平台层面。热迁移后虚拟磁盘重新挂载，设备名变化；虚拟机配置里把磁盘从 scsi 改成 virtio；云控制台里数据盘被误卸载甚至误删除；这些都会造成同样的 PV missing 症状。
云环境里还有个麻烦是磁盘总量对不上。检查cat /proc/partitions时发现容量少了一块，去控制台确认是不是数据盘掉线了，这一点在物理机上反而简单，看灯、看线就行。
3.4 硬件层面：物理磁盘真的坏了吗
物理机上如果底层设备完全看不到，或者看到但 dmesg 全是 I/O error，那就得怀疑硬件了。检查顺序是：确认 RAID 卡/阵列卡状态，进管理界面看磁盘是否 online，有没有 degraded；再看硬盘指示灯。这一步放最后，不是不重要，而是因为大多数 PV missing 都是逻辑层面和配置层面的问题，一开始就奔着硬件去容易做无用功。
4. 确认状态后，怎么让 PV 重新上线
4.1 设备还在但 LVM 没扫到：刷新缓存直接激活
最常见也最好处理的情况。设备在，LVM 元数据也在，只是扫描缓存里没有。执行：
pvscan --cache vgscan vgchange -a y vgdatapvscan --cache的作用是主动刷新 LVM 对块设备的缓存。某些 Linux 发行版用的 LVM 版本会把设备扫描结果缓存在 /etc/lvm/.cache 文件里，如果缓存记录和实际设备状态不一致，就会出现"设备明明在，LVM 就是看不见"的情况。遇到这种，删掉缓存再跑一次 pvscan 往往有奇效：
rm -f /etc/lvm/.cache pvscan vgscan vgchange -a y vgdata删除这个缓存文件是安全的，pvscan 会自动重建。执行完 vgchange 再确认一下：
lvs lsblk /dev/mapper/vgdata-lvdata能挂载就正常挂载，数据验证一下。
4.2 设备路径变了：让 LVM 重新认亲
设备路径变化，但 PV 的 UUID 没变。LVM 对 PV 的识别靠的是磁盘上的 UUID，不是设备名。所以路径变了，理论上 pvscan 全盘扫描一遍就能重新认出来。
实际操作里，如果 pvscan 扫完还是 missing，重点检查 filter。看 /etc/lvm/lvm.conf 里的 devices/ filter 段：
grep -A 5 'filter' /etc/lvm/lvm.conffilter 语法不复杂，a|开头是 accept，r|开头是 reject。比如只接受多路径设备、拒绝其他设备：
devices { filter = [ "a|/dev/mapper/mpath.*|", "r|.*|" ] }如果这个配置导致非多路径环境下的磁盘被拒，就会 PV missing。修改 filter 后执行vgscan重新扫描，不需要重启系统。
4.3 元数据损坏或设备彻底故障：从存档恢复
如果 PV 元数据损坏，或者设备彻底故障，前面的常规手段就不好使了。这时候/etc/lvm/archive和/etc/lvm/backup就是救命稻草。Linux 发行版在 VG 元数据每次变更时，会自动归档到 /etc/lvm/archive，文件名类似vgdata_xxx.vg，带时间戳。vgcfgbackup 则保存当前状态到 /etc/lvm/backup。
恢复前先把当前状态做个快照：
vgcfgbackup vgdata ls -lt /etc/lvm/archive/ | head选一个时间点合适的备份文件，执行恢复：
vgcfgrestore -f /etc/lvm/archive/vgdata_000123.vg vgdata恢复之后重新激活：
vgscan vgchange -a y vgdata必须强调：vgcfgrestore恢复的是 PV 和 VG 之间的"结构关系"，不是文件系统里的用户数据。如果 PV 对应的数据块本身已经物理损坏，恢复元数据顶多让系统把结构对上，但数据区域读不出来照样丢。所以操作前先把当前现场信息都留档，万一恢复错了还能用 vgcfgbackup 再倒回去。
4.4 危险但实用的技巧：pvcreate --restorefile
还有一种情况：PV 的元数据头坏了，或者被人误执行过 pvremove，但磁盘上真正的数据区域还在。这时候有个危险但实用的技巧：用 pvcreate 配合 restorefile 重建 PV 元数据头。
先确认磁盘上还有没有 PV 残留信息：
pvck /dev/sdbpvck 能读出残存的 PV header 内容。然后在 VG 元数据存档里找到原本记录的这个 PV 的 UUID：
grep -A 15 'pv' /etc/lvm/archive/vgdata_000123.vg找到 UUID 之后，用 pvcreate 重建：
pvcreate --restorefile /etc/lvm/archive/vgdata_000123.vg --uuid 原UUID /dev/sdb这条命令会保留原 UUID 重建 PV 元数据，VG 重新识别后就能激活。危险点在于：如果不加 --uuid 乱建，等于制造一块全新的空 PV，原数据区域的映射就断了。所以这个命令只适合明确确定磁盘上数据还在、只是 PV 头坏了的场景，操作前务必备份现场，操作中绝不搞错设备路径。
5. 几个真实场景的处理实录
5.1 场景一：重启后盘符漂移
某台物理机，两块数据盘做 LVM。重启前/dev/sdb是数据盘 A，重启后 lsblk 发现数据盘 A 跑到/dev/sdc去了。pvs显示 missing，但lsblk -f能看到/dev/sdc上有 LVM 标记，UUID 和 VG 里记录的完全一样。
处理很简单：
pvscan --cache /dev/sdc vgscan vgchange -a y vgdata一下就活了。根因是 /etc/fstab 和旧习惯里用了设备名，后来我把系统里所有涉及磁盘的配置都改成了 /dev/disk/by-uuid 和 /dev/mapper 下的稳定路径，盘符漂移的影响就基本消除了。
5.2 场景二：多路径设备被重复识别
有台带存储阵列的服务器，底层双链路。重启后 multipathd 没自动恢复，LVM 扫到了两个独立裸设备/dev/sdb和/dev/sdc，但 VG 里记录的是/dev/mapper/mpatha，于是显示 missing。
先确认 multipath 状态，然后：
systemctl restart multipathd multipath -ll再看 /etc/lvm/lvm.conf 里的 filter 是否只接受多路径设备。我把 filter 改成显式接受/dev/mapper/下的设备，执行vgscan --cache后激活成功。这个坑的关键教训是：多路径环境里，LVM 和 multipath 的配置必须配套，filter 一旦把设备路径掐断，PV missing 是必然结果。
5.3 场景三：双盘线性 LV，其中一块盘彻底掉了
另一个朋友踩的坑。两块盘做一个线性 LV，一块盘物理故障，拔掉之后 LV 无法挂载。线性 LV 的数据是按顺序铺在两块 PV 上的，缺一块就等于文件系统缺失了一段空间，常规挂载肯定失败。
这种情况下如果业务能接受短暂停机，可以考虑vgchange -a y --partial强制部分激活：
vgchange -a y --partial vgdata但限制很多。部分激活后的 LV 是不完整的，访问到缺失区域会直接报 I/O error。能用这个方式把能读的数据快速拷贝出来，就是胜利。操作时必须全程只读，只 serve 备份场景，绝对不能在这种不完整状态下做写入操作，否则损坏范围只会扩大。
5.4 场景四：云数据盘在控制台被误卸载
云服务器上跑了 LVM，某次操作在云控制台把数据盘卸了，没在系统里先 umount。重挂载后发现 pvs 显示 missing。查确认是云平台把磁盘重新挂载后设备名变了。
处理流程：云控制台重新挂载磁盘，回到系统里partprobe刷新分区表，然后：
pvscan --cache vgscan vgchange -a y vgdata这类问题在云环境特别多，根因基本是平台侧挂载状态和系统侧设备扫描状态不同步。平台操作之前先在系统里 umount，是避免这类故障的最基本习惯。
6. 速查表与防患于未然
6.1 PV missing 排查速查表
| 现象 | 可能原因 | 快速处理 |
|---|---|---|
| pvs 显示 [unknown]，设备路径消失 | 盘符漂移/设备未扫描到 | pvscan --cache + vgchange -a y |
| pvs 显示 [unknown]，但 lsblk 能看到设备 | LVM filter 过滤或缓存异常 | 检查 lvm.conf，删缓存重新扫描 |
| pvs 显示 [unknown]，multipath 状态异常 | 多路径服务未恢复 | 重启 multipathd，调整 filter |
| pvs 显示 [unknown]，lsblk 也看不到设备 | 物理掉线/控制器故障 | 先查硬件和平台侧挂载状态 |
| pvs 显示 [unknown]，但 vgcfgrestore 前有备份 | 元数据损坏 | 用 archive 备份恢复 |
| vgchange -a y 失败，提示非一致性 | 部分 PV 缺失 | 确认 LV 映射范围后考虑 --partial |
6.2 让故障不再重演的几个配置习惯
- /etc/fstab 里不要用 /dev/sdX 这种设备名，用 /dev/mapper/vg-lv 或 UUID。设备名会漂移，UUID 不会。
- 定期 vgcfgbackup。系统自带定时任务可能没配，手动加一个 cron，每天把 VG 元数据备份到独立目录甚至备份服务器。PV missing 的时候，一份新鲜的元数据备份能让恢复时间从小时级缩短到分钟级。
- 多路径环境把 lvm.conf 的 filter 配好，并在变更后重启 multipathd 和 vgscan 测试。配好一次，能省掉以后无数个半夜的紧急工单。
- 重要数据的备份不能断。LVM 能恢复的是"结构"，不是"数据"。磁盘物理损坏时唯一可靠的兜底只有备份。
- 监控里加一层 LVM 状态检查，比如检测
pvs输出里是否出现 missing 字样，PV 数量变化就告警。这类故障如果在发生时就发现，比重启后发现业务全挂要容易处理得多。
6.3 一个小脚本，三分钟完成例行体检
分享一个我自己经常用的检查脚本逻辑。核心就几步：扫描 LVM 状态，看 PV 数量是否和预期一致，看 VG 是否有 partial 标记，把异常输出提取出来。
#!/bin/bash VGS="vgdata" for vg in $VGS; do vgdisplay "$vg" | grep -E "VG Name|# PV|Attr" | head -3 done pvs -o pv_name,pv_attr,vg_name,pv_size,pv_free 2>&1 | grep -Ei 'unknown|missing'理论上更完善的做法是把预期 PV 数量写进配置文件，两边对比，不一致就发告警。这套体检逻辑不需要额外依赖，任何 Linux 环境都能跑起来。我自己的习惯是每周跑一次，顺便把 /etc/lvm/backup 同步一份到备份存储。事实证明，PV missing 故障来的时候，这些准备能让你少熬一个通宵。
我个人处理过这么多次 PV missing 之后，最大的体会是：这种故障九成以上都不是硬盘坏了，而是路径、缓存、多路径这类"联系不上"的问题。排查顺序永远别乱——先看设备在不在，再看 LVM 扫不扫得到，最后才动恢复手段。每次操作前先留一份现场记录，比事后猜来猜去强得多。
