企业官网建设流程全解析

LVM基本操作

搞Linux服务器的人，迟早会碰到一个尴尬的场景：系统盘分区的时候估错了容量，结果根目录没跑多久就满了；或者数据盘当初划分了好几个分区，现在某个分区空间告急，另一块却闲着一大半，想挪又不敢乱动。传统分区方案这个时候就很被动，除非重新分区挂载，否则只能眼睁睁看着空间不均。

我第一次遇到这个问题的处理办法是格式化一块新盘，把数据拷过去，再把旧盘重新分区，整个操作折腾了一个通宵，之后我就下定决心换用LVM。LVM全称Logical Volume Manager，逻辑卷管理器，它的核心思路就是把物理磁盘的容量抽象成一个资源池，然后按需切分给不同的逻辑卷。这套机制解决的不只是“空间不够用”的问题，更关键的是让磁盘容量的调整从“需要重新分区”变成了“随手一条命令就可以完成”。

这篇文章会把LVM从概念到实操完整过一遍，包括物理卷、卷组、逻辑卷三层结构，以及卷的创建、扩容、缩容、删除，还有快照功能这些日常用得到的内容。不需要你有多少LVM基础，跟着步骤操作，看完就能在自己机器上跑起来。

1. 理解LVM的三层结构

1.1 物理卷、卷组、逻辑卷分别是什么

LVM之所以灵活，是因为它在物理磁盘和最终挂载的文件系统之间加了两层抽象。最底层叫物理卷（Physical Volume，PV），它就是一块块真实的磁盘分区，也可以是整块磁盘。物理卷之上是卷组（Volume Group，VG），你可以把它理解成一个容量池，一个卷组可以把多块物理卷的容量合并在一起，形成一个统一管理的存储池。最上层是逻辑卷（Logical Volume，LV），这是真正用来格式化文件系统和挂载使用的块设备，卷组里的容量可以切成多个逻辑卷分配给不同的用途。

用生活化的方式来类比：物理卷就是一个个储水罐，卷组是这些储水罐共同连成的一个大蓄水池，逻辑卷就是你从蓄水池里接出去的一根根水管，每根水管供应不同的用水需求。当某个水管的水量不够时，你可以直接从蓄水池调配，不需要重新造水管。

逻辑卷还有两个向下兼容的别名概念：物理卷对应磁盘分区，卷组对应扩容后的磁盘池，逻辑卷对应可伸缩分区。从使用角度看，用户的最终感知就是Linux下多了一个/dev/VGName/LVName这样的设备文件，格式化后像普通分区一样正常使用，但容量可以随时调整。

LVM还有一个容易被忽略的底层参数PE（Physical Extent，物理扩展块）。卷组在创建时会把所有物理卷划分成固定大小的数据块，这个数据块就是PE，默认大小是4MiB。逻辑卷的容量变更，本质上是按PE为单位从卷组中分配或释放空间。理解这个机制对后续容量规划很有帮助，比如后续扩容时如果卷组空间不足，需要先确定是增加新物理卷还是调整PE大小来释放空间。

1.2 LVM相比传统分区的三个核心优势

第一，容量弹性调整。传统分区一旦创建，扩展几乎不可能，除非分区后面有连续空闲空间。LVM的逻辑卷可以在线扩容，缩容也可以在不影响其他逻辑卷的前提下操作，生产环境里这一点非常香。

第二，空间合并与跨盘使用。多块磁盘可以加入同一个卷组，逻辑卷的容量可以跨越物理磁盘的边界。比如说一块500G的盘加上一块200G的盘，卷组就是700G，一个逻辑卷可以在两块盘上各占一部分空间。传统分区方案很难做到这一点，除非上软RAID或者文件系统级别的组合方案。

第三，快照能力。LVM支持对逻辑卷做写时复制快照，可以在不停机的情况下备份文件系统一致性状态。虽然功能上不如专业备份软件花哨，但在很多场景下已经能解决燃眉之急。

当然，LVM也有自己的软肋，比如性能上相比直接使用裸分区会有极小的损耗（主要在IO映射层），配置不当会增加故障排查复杂度，而且默认不支持跨主机迁移（除非整卷组导出导入）。但日常服务器场景下，这些缺点通常不是决定性因素。

2. 实操准备：环境、工具与磁盘规划

2.1 环境要求和LVM工具安装

LVM操作面向的是Linux环境，我实测过的发行版包括Ubuntu、Debian、CentOS、Rocky Linux，在主流内核版本下行为基本一致。新装的系统如果是最小化安装，可能没有预装LVM工具包，可以用包管理器补上。

Ubuntu/Debian系执行：

apt update apt install lvm2 -y

CentOS/Rocky系执行：

yum install lvm2 -y

安装完可以用lvm version验证，能输出版本信息就说明命令行工具已经就绪。LVM在内核里的模块通常是自带的，一般不需要额外加载，除非你用的内核非常精简。

这里有个小建议：LVM工具版本差异对基本操作影响不大，不必刻意追求最新版。关键路径上的命令接口非常稳定，旧版本机器上写的脚本，换到新版本机器也能正常执行。

2.2 磁盘规划与准备

实操开始前，先想清楚你要拿哪块盘来做LVM。如果是虚拟机环境，建议准备一块至少10G的空盘专门做实验，避免误操作影响系统盘。

查看当前磁盘信息：

lsblk fdisk -l

使用lsblk可以直观看到磁盘路径、大小和挂载点，fdisk -l可以查看到更详细的磁盘信息。我的实验环境里有一块/dev/sdb，共20G，没有任何分区和数据，适合用来演示完整流程。

为了模拟真实生产场景，我建议把这块盘分成两个分区再做LVM，这样你能顺便练习“多分区加入同一卷组”的操作。分区用fdisk工具：

fdisk /dev/sdb

进入fdisk交互界面后依次输入以下指令：

n # 新建分区 p # 主分区 1 # 分区号 回车 # 起始扇区默认 +8G # 分区大小8G n # 新建第二个分区 p # 主分区 2 # 分区号 回车 # 起始扇区默认 回车 # 结束扇区默认，吃掉全部剩余空间 w # 写入分区表

创建完成后，用lsblk确认一下，应该能看到/dev/sdb1和/dev/sdb2两个分区。两个分区加起来约20G，正好做后面的卷组合并测试。

提示：生产环境中如果你准备把整块盘用于LVM且这块盘上没有任何数据，可以不分区，直接把/dev/sdb作为物理卷使用。但我个人习惯还是分个区，后续如果想把物理卷换下来或者做排障，有分区表信息会更清晰。如果是在云厂商的云盘上，直接整盘加入PV一般也没问题，厂商的云盘底层已经做了抽象。

2.3 一个清晰的LVM规划目标

我按以下目标来做这次的实操演示，你也可以把它当作参考：

• 物理卷：/dev/sdb1（8G）、/dev/sdb2（约12G）
• 卷组：vg_data
• 逻辑卷1：lv_web，大小10G，挂载到/opt/web，文件系统ext4
• 逻辑卷2：lv_db，大小5G，挂载到/opt/db，文件系统xfs
• 预留部分卷组空间，用于演示在线扩容

这样规划的好处是：逻辑卷的用途分离，扩容时有独立的操作对象，也能验证卷组跨盘分配空间的能力。

3. 完整实操：从物理卷到逻辑卷挂载

3.1 创建物理卷与卷组

先创建物理卷：

pvcreate /dev/sdb1 /dev/sdb2

输出会提示Physical volume "/dev/sdb1" successfully created这样的信息。然后用pvs命令查看物理卷状态：

pvs

刚创建完的时候PE分配情况都是空的，VG列显示空。特别留意VolSize这一列，它会告诉你这个物理卷总共有多少个PE块。假设/dev/sdb1为8G，在4MiB PE下就是2048个PE。

接下来基于这两个物理卷创建卷组：

vgcreate vg_data /dev/sdb1 /dev/sdb2

创建前用vgs看一下：

vgs vgdisplay vg_data

重点看VG Size这一行，如果显示约19.99G，说明两块物理卷的容量成功合并了。vgdisplay的输出里还有Free PE / Total PE，这个字段决定你最多还能创建多大容量的逻辑卷。

3.2 创建逻辑卷并格式化挂载

创建逻辑卷使用lvcreate命令，语法是-n指定名字，-L指定容量大小：

lvcreate -n lv_web -L 10G vg_data lvcreate -n lv_db -L 5G vg_data

创建完成后，逻辑卷设备路径是/dev/vg_data/lv_web和/dev/vg_data/lv_db。同时系统还会在/dev/mapper/目录下生成对应的符号链接，实际使用中这两个路径都可以。

查看逻辑卷状态：

lvs lvdisplay

接下来格式化文件系统。我特意让两个逻辑卷用不同文件系统，方便对比LVM在不同文件系统下的行为差异：

mkfs.ext4 /dev/vg_data/lv_web mkfs.xfs /dev/vg_data/lv_db

创建挂载点并挂载：

mkdir -p /opt/web /opt/db mount /dev/vg_data/lv_web /opt/web mount /dev/vg_data/lv_db /opt/db

用df -h确认：

df -h | grep -E "web|db"

这一步看到/opt/web容量约10G、/opt/db容量约5G，LVM的完整链路就通了。

3.3 配置开机自动挂载

直接mount的方式重启后会失效，需要写入/etc/fstab。推荐用UUID方式挂载，因为逻辑卷在重启后设备名可能变化，UUID更稳定。

获取逻辑卷UUID：

blkid /dev/vg_data/lv_web blkid /dev/vg_data/lv_db

然后在/etc/fstab中添加：

UUID=你的web卷UUID /opt/web ext4 defaults 0 0 UUID=你的db卷UUID /opt/db xfs defaults 0 0

写入之前先用mount -a测试一下fstab配置是否有语法问题，确认无报错后再重启验证。这一步在生产环境尤其重要，fstab写错会导致系统无法正常启动。

注意：有些教程喜欢在fstab里直接写/dev/vg_data/lv_web这种路径。多数情况下能正常工作，但我遇到过个别环境重启后因为设备识别顺序变化导致挂载失败的情况。用UUID能彻底规避这种问题，代价只是多一步blkid。

4. 在线扩容：给逻辑卷增加空间

4.1 卷组空间充足时的扩容步骤

在线扩容是LVM最常用的核心操作。先看一下当前卷组还有多少可用空间：

vgs vgdisplay vg_data | grep Free

如果Free PE对应的空间大于你要扩容的量，直接扩展逻辑卷：

lvextend -L +5G /dev/vg_data/lv_web

这里+5G表示在原有10G基础上增加5G，如果写成-L 15G则是指定扩展到15G，两种写法都可以使用。

扩容逻辑卷只是把空间分配给LV了，文件系统还不知道容量变了，需要执行文件系统的扩容操作。ext4用：

resize2fs /dev/vg_data/lv_web

xfs用：

xfs_growfs /opt/db

注意两者的命令差异：ext系列是针对块设备执行resize2fs，xfs是针对挂载点执行xfs_growfs。xfs_growfs也可以接设备路径，但要求设备必须是已挂载状态。

执行完用df -h确认容量变化。ext4在在线扩容的时候，我建议扩容后顺手跑一次e2fsck -f做文件系统一致性检查，虽然resize2fs本身在线操作做得比较稳，但检查一下更安心。

4.2 卷组空间不足时的处理方式

如果当前卷组Free空间不够，需要先给卷组扩容量。第一步是新增加一块物理磁盘或分区加入卷组：

pvcreate /dev/sdc vgextend vg_data /dev/sdc

如果后续无需再拆走这块盘，vgextend完成后卷组空间就变大了。后续扩容逻辑卷的流程和上面是一样的。

另一种情况是卷组里本身还有空间，但其他物理卷的PE碎片分布不均导致无法一次性分配足够空间。遇到这种情况，pvdisplay查看各物理卷的Free PE分布，必要时用pvmove把某个物理卷的数据迁移到其他盘上，腾出整块盘的空间。

4.3 扩容过程中的注意事项

在线扩容虽然安全，但有几个要点必须牢记。第一，操作顺序不能乱，一定是先扩LV再扩文件系统，顺序反了数据会损坏。第二，扩容前用df和lvdisplay记录原始容量，便于扩容后核对。第三，生产环境扩容给数据库这类在线服务时，建议先做快照，万一扩展过程异常可以回滚。

还有一点：很多人以为扩容必须重启服务，其实LVM的LV扩容和文件系统扩容都是热操作，服务不需要重启，正在写入的数据也不会中断（前提是文件系统没有报错）。这也是LVM相比传统分区方案在生产环境中最大的价值。

5. 缩容操作：高风险场景的谨慎执行

5.1 缩容的完整步骤与顺序

缩容是LVM操作里风险最高的动作，能不做就不做，非做不可时必须严格按顺序来。

缩容分三步，顺序完全不可调换：

1. 先缩小文件系统
2. 再缩小逻辑卷
3. 最后验证数据完整性

前提条件：目标逻辑卷必须是卸载状态，或者至少文件系统是可读写但进程不活跃（强烈建议卸载）。

以缩容lv_web从15G到12G为例：

# 卸载文件系统 umount /opt/web # 强制检查文件系统 e2fsck -f /dev/vg_data/lv_web # 缩小文件系统 resize2fs /dev/vg_data/lv_web 12G # 缩小逻辑卷 lvreduce -L 12G /dev/vg_data/lv_web # 重新挂载 mount /dev/vg_data/lv_web /opt/web

这里resize2fs先改为12G，让文件系统收缩到目标容量，然后lvreduce将LV从15G改为12G。顺序如果反过来，先用lvreduce缩小LV，再resize2fs就会因“设备容量不够”而失败，严重时直接损坏文件系统。

5.2 ext4与xfs在缩容上的关键差异

这个问题是LVM新手最容易踩的坑：xfs文件系统不支持缩容！

是的，xfs官方工具xfs_growfs只支持扩容，没有缩容能力。如果你初始创建时用mkfs.xfs格式化了逻辑卷，那这个逻辑卷的容量只能增加，不能减少。想缩容，唯一的办法是把数据备份出来，重新创建逻辑卷，再把数据拷回去。

所以，如果你有“以后可能要缩容”的需求，尽量用ext4。如果业务必须用xfs，建议创建逻辑卷时按预估上限创建，避免后续缩容踩坑。xfs在超大文件和大文件并发场景下性能确实有优势，但这不代表它没有短板。

5.3 缩容的备份与回滚预案

生产环境缩容之前，务必备份。分摊原则很简单：缩容操作的成功率再高，也不如一份可靠的备份让你睡得安稳。我当时遇到过一次缩容过程中断电阻，restore的时候花了整整半天才恢复数据，从那以后缩容前备份从不省略。

备份方案建议用rsync做文件级备份，快照备份做第二道防线。具体做法：

# 文件级备份 rsync -avx /opt/web/ /backup/web/ # LVM快照备份 lvcreate -s -n lv_web_snap -L 1G /dev/vg_data/lv_web

快照创建后，可以挂载快照验证文件是否完整，确认无误后再执行缩容。如果缩容失败，可以立即从快照恢复数据。

6. 快照与备份：LVM的隐藏亮点

6.1 创建与挂载LVM快照

LVM快照是写时复制（Copy-on-Write）机制，创建瞬间几乎不占空间，后续原始卷数据变化时，变更前的数据块会被复制到快照区域，因此快照会随着原始卷的改动量增大而增大。

创建快照的命令：

lvcreate -s -n lv_db_snap -L 2G /dev/vg_data/lv_db

-s指定了快照类型（snapshot），-n指定快照名称，-L 2G设定快照区域的最大容量。快照区域如果被写满，快照会失效，所以给快照分配的空间要参考你预计在快照保留期内写数据的增量，别给太小。

挂载快照查看数据：

mkdir /mnt/snapshot mount /dev/vg_data/lv_db_snap /mnt/snapshot

查看完卸载：

umount /mnt/snapshot

6.2 快照的合并与删除

如果数据在快照创建后发生变化，你需要恢复原始卷的状态，可以用快照合并：

lvconvert --merge /dev/vg_data/lv_db_snap

执行合并操作需要目标逻辑卷处于卸载状态或文件系统只读挂载。合并完成后，逻辑卷的数据状态会回到快照创建时的样子。

合并操作的结果是不可逆的，执行前一定确认原始逻辑卷上没有需要保留的新数据。如果只是临时看一眼快照内容，不需要合并，直接删除快照即可：

lvremove /dev/vg_data/lv_db_snap

6.3 快照的适用场景与局限性

快照适合做短期一致性备份和误操作快速回滚，尤其是数据库在备份前需要保证一致性状态，可以用快照加冷备份组合。但它不代表完整备份策略，快照区域满了会失效，而且快照和原始卷在同一块物理盘上，磁盘整体故障时快照也救不了你。

我的建议是：快照用于日常小范围误操作的快速恢复，真正重要的业务数据还是要有异地备份。LVM快照让你能睡个安稳觉，但不能替代3-2-1备份原则。

7. 常见问题排查与实际经验

7.1 常见报错与处理方法

我在一次次实操中积累了一些典型问题，列一个速查表供参考。

7.2 实操中的经验教训

我自己在LVM使用中踩过不少坑，挑几个特别典型的说说。

第一个坑是：扩容xfs卷时，lvextend和xfs_growfs执行顺序无所谓，但xfs_growfs必须指定挂载点且当前已挂载，如果指定设备路径，设备必须是已挂载状态。这个细节文档里写得不算明显，我当时卡了很久。

第二个坑：有些云厂商的快照功能（云盘级别）和LVM快照是两回事。云盘快照备份的是整块虚拟磁盘，LVM快照是卷组里的逻辑卷快照，操作对象完全不同。别把二者混淆，备份策略要以业务数据为准。

第三个坑：逻辑卷名不要包含特殊字符，大小写也最好统一。我在生产环境见过有人把LV命名为Lv_Data和lv_data同时存在，虽然技术上不冲突，但排障时看着就头疼。

7.3 LVM日常维护建议

LVM使用一段时间后，建议定期检查以下内容：

• 用vgs和lvs查看卷组和逻辑卷的剩余空间，提前规划扩容。
• 用pvs检查各物理卷的PE分配是否均衡，数据集中在一块盘上会影响性能。
• 用pvscan、vgscan、lvscan定期扫描，确保所有PV在正常状态。
• 逻辑卷接近满容时提前扩容，文件系统在95%以上使用率时性能会明显下降，尤其是ext系列。

生产环境有条件的建议配置监控告警，卷组空间和逻辑卷剩余空间低于阈值时及时通知，避免空间不足导致的业务故障。LVM虽好，但它并不会自动扩容，最终还是靠运维人员的日常关注。

8. 写在最后的一点建议

LVM这套工具链如果用熟了，日常磁盘管理会变得非常从容。从物理卷到卷组再到逻辑卷，概念上其实就是一个“池化和再分配”的思路。你在规划服务器磁盘时，如果有可能出现容量调整的需求，建议从一开始就采用LVM，别等到分区满了再转型，那付出的代价比装系统时多敲几条命令要大得多。

最后分享一个我的实际体会：缩容操作不论看起来多简单，永远不要在生产环境不备份直接执行。xfs不能缩容这点，也最好刻在脑子里。数据这东西，丢一次就足以让你长记性，而LVM的很多坑，恰恰都是在你不以为意的时候冒出来的。