Linux磁盘管理与LVM实战：从分区、PV/VG/LV到扩容缩容与数据迁移

不知道你有没有经历过这样的场景：服务器跑着跑着，一张 df -h 下去，/home 分区已经红了，而旁边的 /var 分区还空着一半多。想扩容？传统分区是死的，要么停机把分区推倒重做，要么含着泪把数据从一块盘挪到另一块盘。我早年在运维岗位上为这种事加过好几次班，直到用上 LVM（逻辑卷管理），才算把这块心病解了。

这篇文章就把 Linux 磁盘管理与 LVM 从原理到实操完整梳理一遍，涉及设备识别、分区表选型、PV/VG/LV/PE 的协作关系、扩容缩容的安全姿势、重装系统前数据盘的处理，以及快照和常见故障的排查经验。不管你是刚入行的运维新手，还是被分区扩容折磨过的“过来人”，这篇内容都能直接用上。

1. 磁盘管理的第一课：先把系统眼里的磁盘和分区搞明白

1.1 设备命名规则：你要操作的到底是哪块盘

Linux 下的磁盘设备都在 /dev 目录下，命名规则大致分三类：

• 传统 SATA/SAS 盘叫做 /dev/sda、/dev/sdb，数字依次往下排，分区就是 /dev/sda1、/dev/sdb2。
• NVMe 固态盘的命名是 /dev/nvme0n1，含义是控制器 0、命名空间 1，分区就是 /dev/nvme0n1p1、p2。
• 云服务器或虚拟机里通常是虚拟磁盘，常见的有 /dev/vda（KVM 环境）、/dev/xvda（Xen 环境），有些虚拟化平台也会提供 /dev/sda 这种兼容命名。

具体盘符叫什么不重要，关键是动手前确认好盘。我登录一台陌生机器的第一件事永远是跑 lsblk，这个命令能把设备、分区、大小、挂载点一屏列全。看清了再动手，能避免 80% 的误操作事故。

bash复制lsblk
# NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
# sda      8:0    0  200G  0 disk
# ├─sda1   8:1    0    1G  0 part /boot
# ├─sda2   8:2    0   50G  0 part /
# └─sda3   8:3    0  149G  0 part /data

1.2 分区表：MBR 和 GPT 怎么选

磁盘要建立分区，分区表类型决定了地盘的划分方式。老式 MBR 分区表最多只能分 4 个主分区（或 3 主分区加 1 个扩展分区），单盘超过 2TB 认不全，分区表没有校验机制，坏了就全盘拉闸。GPT 分区表没有主分区数量限制，单盘支持到 EB 级别，还带 CRC 校验，可靠性高得多。

当前新装系统、新加数据盘，只要容量大于 2TB 就一律用 GPT；小于 2TB 的盘也没有回头选 MBR 的理由——兼容性层面基本没差别，但 GPT 在容错和扩展性上优势明显。

实操中，fdisk 偏向操作 MBR，操作 GPT 建议用 gdisk 或 parted。先快速扫一眼分区信息：

bash复制fdisk -l /dev/sdb
gdisk -l /dev/sdb

提示：新版 fdisk 也能处理 GPT，但不同发行版行为有差异，生产环境求稳，用 parted 或 gdisk 更可靠。

1.3 文件系统与挂载：数据是怎么被“安排”上的

分区只是把硬盘画了格子，真正往里写数据还要经历“创建文件系统”和“挂载”两步。

文件系统常见的有三个，选型思路很明确：

• ext4：老牌、稳定，支持在线扩容和缩容，兼容性最好，很多传统企业环境至今还是它。
• xfs：RHEL/CentOS 7 之后的默认选择，大文件和高并发场景性能好，但只支持扩大、不支持缩小。这是很多人后来在 LVM 缩容时踩大坑的根源。
• btrfs：特性多（快照、子卷、压缩），但生产环境的长期稳定性验证不如前两者充分。

挂载这个动作，就是让某个目录成为文件系统的访问入口：

bash复制mkdir /data
mount /dev/vg-data/lv-data /data

如果希望重启后自动挂载，就写进 /etc/fstab。这里我强烈建议用 UUID 而不是设备名，设备名可能在重启后因为盘符顺序变化而错位，UUID 是硬盘级别的固定标识：

bash复制blkid /dev/vg-data/lv-data   # 拿到 UUID
echo 'UUID=xxxx /data xfs defaults 0 0' >> /etc/fstab

有过一次因为设备名错位导致开不了机的经历后，你会彻底记住这个习惯。

1.4 传统分区的三个痛点

传统分区方案在物理机上跑了那么多年，最大的问题有三个：

• 扩容难。分区建立后大小固定，想在线扩几乎不可能，改分区表往往要重启、要停业务。
• 空间分配不均衡。当初安装时规划小了的分区经常爆盘，旁边却躺着几十 G 空闲分区用不上。
• 无法跨盘聚合。一块盘不够用时只能重新挂新盘、迁移目录，没有“把两块盘并成一块用”的机制。

这三个痛点，就是 LVM 存在的根本原因。它把“物理磁盘”和“逻辑分区”之间加了一层映射，让空间分配变成了可以随时改的动态过程。

2. LVM 机制拆解：PV、VG、LV、PE 到底怎么配合

2.1 四个核心角色，一次说清

LVM 里四个基础概念就像一套仓库管理系统：

• 物理卷 PV（Physical Volume）：一块磁盘或一个分区，是被纳入管理的基本单元。
• 卷组 VG（Volume Group）：多个 PV 聚合成的“存储资源池”。
• 逻辑卷 LV（Logical Volume）：从资源池里切出来的一个逻辑分区，文件系统就建在它上面。
• 物理扩展块 PE（Physical Extent）：VG 分配空间的最小单位，默认 4MiB，LV 的容量变化本质是 PE 数量的增减。

这样类比可能更好懂：你租了一间大仓库（VG），仓库里摆了几排货架（PV），货架上的每个抽屉都按同样大小的小格（PE）编号，你需要时用箱子（LV）在货架上划分区域，数据就往箱子里放。箱子大小随时能改，想扩就多占几个小格，想移就把箱子从 A 货架挪到 B 货架。

四个概念的对应关系和技术作用见下：

2.2 PE 到文件系统的映射过程

LVM 本质上是一个块设备的映射层。创建 LV 时，LVM 会把 VG 里一些 PE 分配给这个 LV，LV 在逻辑上由“逻辑扩展块 LE（Logical Extent）”组成，每个 LE 通过映射表对应到某个 PV 上的一个 PE。文件系统看到的是一整块连续的逻辑卷，它根本不知道底层的 PE 散落在两块物理盘上。

所以扩容、缩容、迁移，本质都是在改这张映射表，不碰数据本身。这也是为什么 LVM 的扩展速度很快——它只是重新分配了 PE 映射关系，数据不需要搬动。

这些映射关系和卷组描述信息，存放在每块参与 VG 的 PV 头部一小块元数据区域里。这也是 LVM 数据盘在系统重装后能被新系统“认回来”的依据。

2.3 相比传统分区，LVM 值钱在哪

• 跨盘聚合：几块盘合成一个 VG，不再受单盘容量限制。
• 在线调整：LV 容量可以在业务不中断时扩大，前提是文件系统本身支持。
• 快照：秒级创建逻辑卷快照，用于备份一致性和回滚测试。
• 热迁移：数据可以从一块物理盘在线挪到另一块，支持旧盘下线、坏盘替换。

有了这几点，运维在面对容量告警、硬盘更换、服务器扩容时，操作空间和以前完全不是一个量级。

3. 从零搭建一套 LVM：完整实操与参数意图

3.1 动手前的设计：先想清楚再敲命令

新加两块盘 /dev/sdb 和 /dev/sdc，目标是把它们合成一个卷组 vg-data，在里面建一个 100G 的逻辑卷挂到 /data。

动手前先确认几件事：

• 盘上有没有旧数据。lsblk -f 能看到文件系统类型，有内容的盘绝对别直接 pvcreate。
• 挂载点规划。数据目录、日志目录、备份目录，按后续增长情况分别建 LV。
• 文件系统选型。有缩容需求的目录选 ext4，明确三年内只扩不缩、追求大数据量性能的选 xfs。
• 卷组和逻辑卷命名。建议用“用途”做名字，vg-data、lv-mysql 这类名字过半年你再看也能一眼懂。

命名这环节看似小事，实际能省很多事。我见过不少人建了个 vg0、lv0，半年后自己都忘了里面装的是什么。

3.2 完整命令流程

第一步，确认目标盘。看到 /dev/sdb、/dev/sdc 都是空盘，大小各 1TB：

bash复制lsblk
# sdb       8:16   0    1T  0 disk
# sdc       8:32   0    1T  0 disk

第二步，建 GPT 分区并标记为 LVM 类型。虽然 LVM 可以直接在整块裸盘上创建 PV（pvcreate /dev/sdb），但我建议还是建分区，保留后续灵活性。用 parted：

bash复制parted /dev/sdb mklabel gpt
parted /dev/sdb mkpart primary 0% 100%
parted /dev/sdb set 1 lvm on

parted /dev/sdc mklabel gpt
parted /dev/sdc mkpart primary 0% 100%
parted /dev/sdc set 1 lvm on

第三步，创建 PV：

bash复制pvcreate /dev/sdb1 /dev/sdc1
pvs
# PV         VG     Fmt  Attr PSize   PFree
# /dev/sdb1          lvm2 ---   1.00t  1.00t
# /dev/sdc1          lvm2 ---   1.00t  1.00t

第四步，创建 VG，统一管理两块盘。如果希望 VG 内空间分配单位更细，可以用 -s 指定 PE 大小，默认 4MiB 够用：

bash复制vgcreate vg-data /dev/sdb1 /dev/sdc1
vgs
# VG      #PV #LV #SN Attr   VSize VFree
# vg-data   2   0   0 wz--n- 2.00t 2.00t

第五步，创建 LV。-n 给名字，-L 指定大小：

bash复制lvcreate -n lv-data -L 100G vg-data
lvs
# LV      VG      Attr       LSize  Pool Origin Data%
# lv-data vg-data -wi-a----- 100.00g

第六步，创建文件系统并挂载。我这里用 xfs 演示，因为它在 RHEL/CentOS 系很常见：

bash复制mkfs.xfs /dev/vg-data/lv-data
mkdir -p /data
mount /dev/vg-data/lv-data /data

第七步，写入 /etc/fstab 实现开机自动挂载。先用 blkid 拿到 UUID：

bash复制blkid /dev/vg-data/lv-data
# /dev/vg-data/lv-data: UUID="xxxx-xxxx" TYPE="xfs"
echo 'UUID=xxxx-xxxx /data xfs defaults 0 0' >> /etc/fstab
mount -a    # 用这条命令验证 fstab 配置是否正确

到这里，一套两盘聚合的 LVM 环境就搭起来了。你可以在 /data 下开始写数据，两块物理盘对上层目录完全透明。

3.3 验证状态与常用查看命令

日常巡检看三个简写命令就够：

bash复制pvs    # 物理卷概览
vgs    # 卷组概览，关注 VFree 剩余空间
lvs    # 逻辑卷概览，关注 LSize 和 Attr

看详细属性用 pvdisplay、vgdisplay、lvdisplay。排查问题时一上来用简写，锁定了再上全量信息，效率更高。

3.4 新手最容易踩的几个小坑

• 新建的 LV 在 /dev 下看不到：如果路径写 /dev/vg-data/lv-data 找不到，检查 LV 是否处于激活状态，用 lvchange -ay /dev/vg-data/lv-data 激活。
• 分区表创建后内核没重新识别：执行 partprobe 让内核重新读取分区表，避免“创建了分区但找不到 /dev/sdb1”的情况。
• fstab 配错了导致开不了机：改完 fstab 一定先执行 mount -a 通不通，不通就先别重启。

4. 容量告急怎么办：扩展、缩容和迁移的实战姿势

4.1 在线扩容：先扩 LV，再扩文件系统

扩容是 LVM 最常被用到的一个功能。分三种场景处理：

场景一，VG 里还有空闲空间，直接扩。比如 vg-data 还剩 500G，给 lv-data 增加 20G：

bash复制lvextend -L +20G /dev/vg-data/lv-data

场景二，VG 本身也没空间了，得先扩 VG。新加一块 1T 盘 /dev/sdd：

bash复制pvcreate /dev/sdd1
vgextend vg-data /dev/sdd1
lvextend -L +100G /dev/vg-data/lv-data

场景三，云盘在控制台扩容了，但系统里容量没涨。这块要分步骤：云盘扩容后先重建分区大小，再扩 PV，再扩 LV，再扩文件系统。

以 /dev/vdb 为例，控制台把云盘从 100G 升到了 200G：

bash复制growpart /dev/vdb 1          # 扩展分区 vdb1 到整盘
pvresize /dev/vdb1           # 扩展 PV 大小
pvs                          # 确认 PSize 从 100G 变 200G
lvextend -l +100%FREE /dev/vg-data/lv-data

上面扩完 LV 只是第一步，文件系统还没变，df -h 看到的大小仍然不变。继续：

bash复制# ext4 文件系统
resize2fs /dev/vg-data/lv-data

# xfs 文件系统
xfs_growfs /data

注意：ext4 用 resize2fs，后面接的是设备路径；xfs 用 xfs_growfs，后面接的必须是挂载点。顺序千万不能反——必须先扩 LV 再扩文件系统。如果文件系统认为底层容量没变就执行 resize 报错，反过来会导致 LV 和文件系统容量不一致。

这里解释一下“为什么能在线扩容”：LVM 扩 LV 只是改 PE 映射表，不搬数据；而 ext4 和 xfs 在文件系统头部有容量描述信息，resize2fs 和 xfs_growfs 作用就是把这份描述改成新大小，改完后文件系统就能用新的空间了。整个流程不涉及数据搬移，所以可以在业务不中断时执行。

4.2 缩容：不到万不得已别碰的高危操作

先说结论：xfs 不能缩容，ext4 可以缩，但必须在离线（umount）状态下操作，并且顺序是“先缩文件系统，再缩逻辑卷”。

为什么说它高危？如果你先缩了 LV，再把文件系统缩到 LV 的新容量，文件系统尾部的数据会超出 LV 边界，直接丢失。反过来先缩文件系统，再缩 LV，才能保证数据安全。

完整的 ext4 缩容流程如下：

bash复制# 1. 停止业务，卸载文件系统
umount /data

# 2. 强制检查文件系统，避免有未解决的错误
e2fsck -f /dev/vg-data/lv-data

# 3. 先把文件系统缩到目标大小，比如缩到 80G
resize2fs /dev/vg-data/lv-data 80G

# 4. 再缩 LV 到同样大小
lvreduce -L 80G /dev/vg-data/lv-data

# 5. 重新挂载
mount /data

每步之间都要确认命令输出没有报错。缩容完成后再用 df -h 和 lvdisplay 对照一次，两边大小必须一致。

我的实际经验是：缩容适合用在“历史规划失误导致 LV 过大”的场景，而且要提前做快照或备份。生产环境凡是遇上 xfs 卷空间规划过大想收回来的，我都不建议硬缩，而是建新卷、用 rsync 把数据倒过去，再把老卷删掉，这样的风险远低于原地缩容。

4.3 pvmove：把数据从坏盘上平稳挪走

某块物理盘 PFree 变小、出现坏道，或者单纯想换一块更快的新盘，pvmove 就是为你准备的。它可以在线把一块 PV 上的数据全部挪到 VG 内的其他 PV 上，期间业务无感。

bash复制pvmove /dev/sdb1

执行完后，/dev/sdb1 就从“有数据的活动 PV”变成空盘。确认无数据后即可从 VG 中移除：

bash复制vgreduce vg-data /dev/sdb1
pvremove /dev/sdb1

这套操作在物理服务器换盘场景里特别好用——旧盘可以物理拔掉，新盘入场后 pvcreate + vgextend，再把数据挪回来，全程不需要停业务。

5. 重装系统前的 LVM 数据盘处理：最容易翻车的场景

5.1 为什么“不卸载直接重装”很危险

很多人装 Linux 时喜欢把整块系统盘甚至多块盘都纳入 LVM，然后在上面建 lv_root、lv_home、lv_var。这套方案平时用着很爽，但到了“重装系统、保留数据盘”这类场景，就会踩出大坑。

举个真实的例子：某台云主机安装系统时，安装向导里把数据盘也加入了系统卷组，当作 /home 的容量扩展。后来用户重装系统，只重置了系统盘，数据盘没有清空。开机后新系统初始化了新的同名卷组，数据盘上还带着旧卷组的元数据，两个卷组同名，系统自动激活了一个不是用户预期的那一个。用户一登进去，/home 里空空如也，以为自己数据全没了，急得差点当场哭出来。

这个问题的本质在于：LVM 元数据写在每块 PV 的头部，系统重装不会自动清掉数据盘上的 LVM 标记。如果新系统里又建了同名的 VG，旧盘一旦被激活，就会出现“卷组名字重复”的冲突，具体表现为新系统挂到了错的卷上，或者 LV 起不来，又或者数据目录看起来是空的但实际数据还在另一张映射表里。

云电脑和云主机的重装场景尤其要警惕：用户只是想把系统重装一遍，数据盘的 LVM 结构和数据理应保留，但如果不做善后，重装后的系统很可能认不出或认错旧卷组。

5.2 重装前的标准处理流程

先区别两种情况。

情况一：数据盘已经独立成 VG，重装后想继续直接用。这时只需要把旧卷组安全停用，避免重装过程中被人为激活：

bash复制vgchange -an vg-data

执行完再用 vgs 确认 Attr 那一列状态变成 wz--n-（n 表示 inactive）。停用后数据盘在系统层面就是一块带 LVM 标记的“休眠盘”，重装过程不会干扰系统盘的引导和初始化。

情况二：数据盘上确实有旧数据，且不再打算保留。那就彻底删除 LVM 关联：

bash复制umount /data
lvremove /dev/vg-data/lv-data
vgremove vg-data
pvremove /dev/sdb1

这样操作完，数据盘是干净的裸盘或普通分区，重装完再重新规划，不会遗留任何 LVM 元数据。

还有一种安全做法，适合要把数据盘从原系统正式“交接”给新系统：使用 vgexport 完成卷组卸载，把元数据中的 VG 标记为“已导出”，然后在新系统中用 vgimport 导入。这组命令能解决不同系统之间 LVM 元数据 ID 冲突的问题：

bash复制# 旧系统上执行
umount /data
vgexport vg-data

# 拆盘、重装或转移到新系统后，新系统上执行
vgscan
vgimport vg-data
vgchange -ay vg-data
mount /data

5.3 重装系统之后怎么找回旧数据盘

如果重装时没来得及做任何处理，也别慌，找回数据盘的路径是有的。

第一步，扫描元数据：

bash复制pvscan
vgscan

pvscan 会列出所有能被识别的 PV，包括旧系统留下的那些。vgscan 会尝试重建卷组信息。

第二步，激活卷组：

bash复制vgchange -ay vg-data

激活后 lvs 能看到 LV，再挂载即可。如果新系统已经存在同名 VG，或者卷组 ID 冲突，改个名字再挂：

bash复制vgrename vg-data vg-data-old
vgchange -ay vg-data-old
mkdir /mnt/olddata
mount /dev/vg-data-old/lv-data /mnt/olddata

这样做的目的是“先找回数据，再谈怎么规划”，而不是直接格式化。

5.4 引入 vgimport 的完整重装交接案例

之前处理过一个比较典型的案例，我把完整链路贴出来供参考：

旧服务器上有 /dev/sdb1 参与了 vg-old，数据要整体迁到新服务器。手工记录太容易出错，我用导出/导入方式处理。

旧服务器：

bash复制umount /data
vgexport vg-old
vgdisplay -v vg-old     # 确认 exported 状态

物理拔盘，插到新服务器后：

bash复制pvscan                  # 识别旧 PV
vgimport vg-old         # 导入卷组
vgchange -ay vg-old
mkdir -p /data
mount /dev/vg-old/lv-data /data

整个过程没有任何数据拷贝，就是元数据层面的导入导出，耗时几分钟。这也是 LVM 在数据迁移场景里最值得称道的一点。

6. 快照、元数据备份和排错手册：关键时刻能救命

6.1 快照的原理和正确用法

LVM 快照基于 COW（Copy-on-Write）机制。创建快照后，原始 LV 上每次要覆写数据时，系统先把即将被覆盖的旧数据拷贝到快照空间保存，所以快照里保留的是“创建时刻的原始数据”。快照创建时不用拷贝全量数据，因此秒级完成、对业务影响极小。

创建快照：

bash复制lvcreate -s -n lv-data-snap -L 20G /dev/vg-data/lv-data

-s 指定创建快照，-n 命名，-L 指定快照大小。快照空间不用和原 LV 等大，只保存“创建后变化的数据”，一般给原 LV 数据的 10%~20%，比如原 LV 100G 就给 20G 快照空间，前提是短期内变化量可控。

快照的实际用途有三类：

• 数据库备份前打一致点，挂载快照卷做备份，业务侧零影响。
• 重大变更（升级、批量改配置）前留一个回滚点，出问题了直接快照回滚。
• 把快照卷挂载到另一个目录，查看历史状态，不影响线上数据。

挂载快照做验证：

bash复制mkdir /mnt/snap
mount /dev/vg-data/lv-data-snap /mnt/snap
# 查看完卸载并删除快照
umount /mnt/snap
lvremove /dev/vg-data/lv-data-snap

注意：快照空间一旦写满，快照会变成 inactive，直接失效且无法恢复。所以快照别建得太小，也别把快照当持久备份一直挂着，它的定位是短期一致性保护。

6.2 元数据备份：不见得用的上，但出事时能救命

LVM 卷组的所有映射关系都记录在 PV 头部元数据里。日常变更前做一次元数据备份是成本极低的保险：

bash复制vgcfgbackup vg-data

备份文件默认生成在 /etc/lvm/backup/vg-data。如果 VG 元数据损坏，vgscan 找不到卷组，可以用 vgcfgrestore 恢复：

bash复制vgcfgrestore vg-data

这比用第三方工具扫描重建可靠得多。建议每次对 VG/LV 做扩容、缩容、删除类的操作前，都先执行一次 vgcfgbackup。

6.3 常见故障排查手册

翻车不可怕，可怕的是出了问题不知道去哪定位。这张表是我实践里积累的常用排查路径：

还有一个常见场景：系统里同时存在多个旧 VG 名字，vgscan 后名字冲突。处理顺序是 vgrename 改名，然后 vgchange -ay 激活，最后挂载。千万别在冲突时直接 vgremove。

6.4 设计层面的几条长期建议

• /boot 分区不要放进 LVM。GRUB 早期引导阶段对 LVM 的支持虽然已经可用，但独立分区能把引导风险和存储管理彻底隔离。
• 系统盘的数据盘分开建 VG。vg-system 管系统根卷，vg-data 管业务数据，重装系统时数据盘的处理会干净很多。
• VG 里预留 10%~20% 空闲空间。这些空间既给扩容留余量，也给快照留空间，临时救急时不必先找新盘。
• 命名规范稳定下来。vg-项目名、lv-用途的命名方式值得坚持，服务器多了以后这三代人都能看懂。
• 集群环境里配共享存储时，LVM 要和 fencing 机制配合使用。fence 负责隔离异常节点，避免多个节点同时激活同一个 LV 导致数据损坏，别忽略这块配置。

最后说点我的习惯

做 Linux 磁盘管理这么多年，我最大的体会是：磁盘可能不是服务器里最贵的硬件，但绝对是最不能瞎搞的部分。LVM 给了你很强的灵活性，但灵活性也是一把双刃剑，操作不规范时破坏力同样翻倍。

我每次新建 VG 都会预留 10%~20% 未分配空间，给快照和应急扩容留出缓冲；涉及扩缩容操作前固定执行一次 vgcfgbackup；数据盘一律独立建 VG，宁可多一个卷组名，也不把系统卷和数据卷混在一锅。另外，xfs 的卷缩不了，建卷之前把未来两三年的容量规划想清楚，能省掉后续无数麻烦。

这套方法论不是哪本书上教的，是我在一次又一次的凌晨事故里换来的。按这个思路管理磁盘，日子会好过很多。