Linux LVM:故障排查与数据恢复指南

LVM 是 Linux 系统核心磁盘管理工具,运维过程中常出现 VG 丢失、LV 激活失败、PV 异常、快照失效、磁盘只读等各类故障,极易影响业务运行。本文整理全套 LVM 运维排错方案,汇总排查命令、常见故障修复流程、元数据备份恢复方法,同时提供应急操作清单与常态化预防策略,适配生产环境各类突发问题。
一、LVM 排查的”急救箱”
# 看 PV 状态 $ pvs $ pvdisplay $ pvs -a # 包括 missing 的 # 看 VG 状态 $ vgs $ vgdisplay $ vgscan # 看 LV 状态 $ lvs $ lvs -a # 包括隐藏的 internal LV $ lvscan # 看内核级 device-mapper 状态 $ dmsetup info $ dmsetup ls $ dmsetup table # 看系统日志 $ dmesg | grep -i lvm $ dmesg | grep -i dm- $ journalctl -u lvm2-monitor
二、常见故障速查表
故障 1:VG 找不到 / “Volume group not found”
$ vgscan Reading all physical volumes. This may take a while... No volume groups found
诊断:
# 1. 设备还在吗? $ ls -l /dev/sdb $ fdisk -l /dev/sdb # 2. PV 元数据在吗? $ pvcreate --uuid <uuid> --restorefile /etc/lvm/backup/vg_data /dev/sdb # 3. 看备份 $ ls /etc/lvm/backup/ $ cat /etc/lvm/backup/vg_data
修复:请参考后面会讲到的 vgcfgrestore 命令。
故障 2:LV 无法激活 “Failed to activate”
$ lvchange -ay vg_data/lv_db Failed to activate lv_db
诊断:
# 1. 看是否有 VG 缺失 PV $ vgs --partial --verbose vg_data # 2. 检查 PV $ pvdisplay /dev/sdb # 3. 强制激活(危险,可能丢数据) $ lvchange -ay --partial vg_data/lv_db
故障 3:thin pool 满了,所有 thin LV 只读
$ touch /mnt/thin/test touch: cannot touch '/mnt/thin/test': Read-only file system
修复:
# 1. 看占用率 $ lvs -o lv_name,data_percent,metadata_percent vg_data # 2. 清理大快照 $ lvremove /dev/vg_data/lv_old_snap # 3. 扩 pool $ lvextend -l +100%FREE vg_data/tp_data # 4. thin LV 自动恢复可写
故障 4:device-mapper busy,无法卸载/激活
$ umount /mnt/lv_demo umount: /mnt/lv_demo: target is busy
诊断:
# 看谁在用 $ lsof /mnt/lv_demo $ fuser -m /mnt/lv_demo # 看打开数 $ lvs -o lv_name,lv_attr vg_data # 第六位 'o' = open
修复:
# 1. 杀掉进程 $ fuser -km /mnt/lv_demo # 2. 强制卸载(仅 ext 系列,xfs 不支持) $ umount -l /mnt/lv_demo
故障 5:PV 显示 “missing”
$ pvs PV VG Fmt Attr PSize PFree /dev/sdb vg_data lvm2 a-- 500.00g 0 [unknown] vg_data lvm2 a-m 500.00g 500.00g # ← 缺失!
诊断:
# 设备名变了? $ ls -l /dev/sd* $ dmesg | tail # 找 LVM 元数据 $ pvscan $ blkid | grep LVM2
修复:
# 1. 如果盘还在但设备名变了 $ pvcreate --uuid "原 UUID" /dev/sdc # 用新设备名恢复元数据 # 2. 找回 VG(详见后续章节) $ vgcfgrestore vg_data # 3. 移除 missing PV $ vgreduce --removemissing --force vg_data
故障 6:快照 invalid
$ lvs LV Attr LSize lv_demo_snap swi-I-s--- 1.00g # ← I = invalid
原因:snapshot area 写满。
修复:
# 1. 删除失效快照 $ lvremove -f /dev/vg_data/lv_demo_snap # 2. 重建 $ lvcreate -L 2G -s -n lv_demo_snap /dev/vg_data/lv_demo
三、诊断流程图
业务报错(如 FS 只读、LV 无法挂载) │ ├─ 看 dmesg / journalctl → 硬件层错误? │ └─ 是:换盘 / 修复硬件 │ ├─ pvs / vgs / lvs → LVM 状态异常? │ ├─ missing PV → vgcfgrestore / vgreduce --removemissing │ ├─ thin pool 满 → 扩 pool / 删快照 │ ├─ LV 不存在 → lvcreate 恢复 │ └─ 全部正常 → 检查 FS(见下方) │ └─ df / mount → FS 错误? ├─ ext4: e2fsck 修复 └─ xfs: xfs_repair 修复(必须先卸载)
四、备份恢复前的关键操作
# 1. 先备份 metadata(重要!) $ vgcfgbackup vg_data # 备份到默认位置 # 2. 把当前状态记录下来 $ pvs > /tmp/pvs.bak $ vgs > /tmp/vgs.bak $ lvs > /tmp/lvs.bak $ lvs -a > /tmp/lvs-a.bak # 3. 看 metadata 历史 $ ls -lt /etc/lvm/archive/vg_data_*.vg # 4. 不要立刻操作!先看清楚
五、lvm 配置文件
/etc/lvm/lvm.conf中关键字段:
# 备份路径 backup = 1 backup_dir = "/etc/lvm/backup" archive_dir = "/etc/lvm/archive" # 设备过滤器(经常出错!) # 允许所有设备: filter = [ "a|.*|" ] # 拒绝 loop 设备: # filter = [ "r|/dev/loop.*|", "a|.*|" ]
修改后必须重启或:
$ lvmetad -f # 强制刷新(较老版本)
现代 lvm2 用 lvmpolld 或直接重启服务。
六、vgcfgrestore 救命的命令
这是 LVM 排错的”杀手锏”。
6.1 看历史 metadata
$ ls -lt /etc/lvm/archive/vg_data_*.vg | head -rw------- 1 root root 4096 Jun 23 02:00 vg_data_00010-1234567.vg -rw------- 1 root root 4096 Jun 22 18:00 vg_data_00009-1234567.vg -rw------- 1 root root 4096 Jun 21 12:00 vg_data_00008-1234567.vg
文件格式:vgname_<seq>-<uuid>.vg
6.2 看指定版本的 metadata
# 看 3 个改动前的版本 $ less /etc/lvm/archive/vg_data_00007-1234567.vg
内容是文本,类似:
contents = "Text Format Volume Group"
version = 1
description = "Created *before* executing 'lvextend...'"
creation_host = "server01"
creation_time = 1700000000
...
physical_volumes {
pv0 {
device = "/dev/sdb"
...
}
pv1 {
device = "/dev/sdc"
...
}
}
logical_volumes {
lv_db {
...
}
}
6.3 恢复到指定版本
# 1. 确认要恢复的版本 $ head -1 /etc/lvm/archive/vg_data_00007-1234567.vg contents = "Text Format Volume Group" version = 1 description = "Created *before* executing 'lvreduce /dev/vg_data/lv_db...'" # 2. 恢复 $ vgcfgrestore -f /etc/lvm/archive/vg_data_00007-1234567.vg vg_data Restored volume group vg_data. # 3. 激活 $ vgchange -ay vg_data # 4. 验证 $ lvs vg_data
6.4 找不到正确的 backup?
# 看 metadata 的位置和 UUID $ cat /etc/lvm/backup/vg_data | grep -i uuid
也可以从未损坏的 PV 里恢复:
# 1. 看 PV 上的 metadata $ pvs --verbose /dev/sdb # 2. 用 PV 恢复 $ pvcreate --restorefile /etc/lvm/backup/vg_data --uuid <pv-uuid> /dev/sdb
七、PV 误删的恢复
# 场景:vgreduce 误删了 PV,VG 数据"消失" # 1. 看 backup $ ls /etc/lvm/backup/ # 2. 看 PV 上是否有残留的 metadata $ strings /dev/sdb | grep -A 2 "LVM2"
如果 PV 上 metadata 还在:
# 用 metadata 重建 PV $ pvcreate --uuid <原 UUID> --restorefile /etc/lvm/backup/vg_data /dev/sdb # 恢复 VG $ vgcfgrestore vg_data # 激活 $ vgchange -ay vg_data
八、LV 误删的恢复
LV 删除后理论上无法恢复,但:
8.1 立刻做(关键!)
# 1. 立刻停掉所有可能写入的进程 $ umount /mnt/lv_demo # 2. 不要做 fsck,不要做 resize # 3. 不要对底层 PV 做任何操作
8.2 看 metadata 备份
$ ls /etc/lvm/archive/vg_data_*.vg
找到删除前的版本。
8.3 恢复 VG metadata
# 用备份恢复 VG $ vgcfgrestore -f /etc/lvm/archive/vg_data_00005-1234567.vg vg_data # 检查 LV 是否回来 $ lvs vg_data
8.4 文件系统层修复
LV 回来了,但文件系统可能不一致:
# ext4 $ e2fsck -f /dev/vg_data/lv_demo # xfs $ xfs_repair /dev/vg_data/lv_demo
8.5 实在恢复不了怎么办?
- 从备份恢复(这是为什么备份重要);
- 用 testdisk / photorec 尝试扫描底层 block;
- 找专业数据恢复公司。
九、生产环境故障应急清单
把这份清单打印出来贴墙上:
- 立刻:停止写入,umount 所有相关 LV
- 不要:立刻重做 LVM 操作、立刻 fsck
- 收集:dmesg、pvs、vgs、lvs -a、pvdisplay、lvdisplay
- 备份:
cp /etc/lvm/backup/* /safe/path/ - 检查:metadata 历史 (
ls /etc/lvm/archive/) - 恢复:
vgcfgrestore - 验证:
e2fsck / xfs_repair - 挂载:mount
- 通知:相关业务方恢复情况
十、预防胜于救援
# 1. 每天备份 metadata 到安全位置 $ crontab -e 0 3 * * * cp -a /etc/lvm/backup/* /backup/lvm-metadata/ # 2. 监控 metadata 序列号变化 $ vgs -o vg_name,vg_mda_count,vg_seqno # 3. 启用 lvmetad 自动缓存(性能更好) $ lvmconf | grep use_lvmetad use_lvmetad=1 # 4. 启用 lvm2-monitor 服务(自动检测) $ systemctl enable lvm2-monitor $ systemctl start lvm2-monitor
十一、本篇小结
LVM 排错的核心思路:
- 不要慌,先收集信息(
pvs/vgs/lvs -a/dmesg); - 不要立刻操作,先备份当前状态;
- 用
/etc/lvm/backup/和/etc/lvm/archive/恢复; vgcfgrestore是救命稻草。
三大日常预防措施:
- 定期备份 metadata;
- 启用 lvm2-monitor 服务;
- 监控 SMART 提前换盘。
结语
本文系统梳理了 LVM 各类典型故障的诊断逻辑与恢复方案,明确了以信息收集、状态备份、元数据恢复为核心的排错思路,重点讲解了 vgcfgrestore 核心恢复命令。规范的应急操作流程可高效解决绝大多数 LVM 故障,同时常态化备份、监控巡检等预防手段,能从根源降低生产环境 LVM 故障发生率。
以上关于Linux LVM:故障排查与数据恢复指南的文章就介绍到这了,更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章,希望大家以后多多支持码云笔记。
如若内容造成侵权/违法违规/事实不符,请将相关资料发送至 admin@mybj123.com 进行投诉反馈,一经查实,立即处理!
重要:如软件存在付费、会员、充值等,均属软件开发者或所属公司行为,与本站无关,网友需自行判断
码云笔记 » Linux LVM:故障排查与数据恢复指南
微信
支付宝