磁盘满了别慌！Linux扩容全攻略，从云平台到文件系统一网打尽

最近接到客户扩容需求，正好没想好今天些什么。今天就来盘盘磁盘扩容吧！！这种事情估计每个做运维的兄弟都遇到过。刚开始做运维那会儿，遇到这种情况就是一顿清理日志，删删删，但治标不治本啊。后来慢慢学会了磁盘扩容，发现这玩意儿其实没那么复杂，但坑还是挺多的。

今天就跟大家分享一下Linux磁盘扩容的各种姿势，从云平台扩容到不同文件系统的处理方法，我都会详细说一遍。用的是Debian 13做演示，其他发行版大同小异。

扩容前的准备工作

在动手之前，我们得先搞清楚当前的磁盘情况。这就像看病要先诊断一样，不能上来就开刀。

# 查看磁盘使用情况
df -h

# 查看分区信息
lsblk

# 查看物理卷信息（如果使用了LVM）
pvs

# 查看卷组信息
vgs

# 查看逻辑卷信息
lvs

我这个是有做逻辑卷的

#df -h 输出解释
Filesystem                   Size  Used Avail Use% Mounted on
udev                         903M     0  903M   0% /dev          # 设备文件系统，903MB大小，使用0%，挂载在/dev
tmpfs                        188M  1.2M  186M   1% /run         # 临时文件系统，188MB大小，已使用1.2MB(1%)，挂载在/run
/dev/mapper/debian--vg-root  5.6G  3.1G  2.3G  58% /            # 根分区，LVM卷，5.6GB大小，已使用3.1GB(58%)，挂载在/
tmpfs                        936M     0  936M   0% /dev/shm     # 共享内存临时文件系统，936MB大小，使用0%，挂载在/dev/shm
tmpfs                        5.0M  8.0K  5.0M   1% /run/lock    # 锁文件临时文件系统，5MB大小，已使用8KB(1%)，挂载在/run/lock
tmpfs                        1.0M     0  1.0M   0% /run/credentials/systemd-journald.service  # systemd日志服务凭证目录，1MB大小，使用0%
tmpfs                        936M     0  936M   0% /tmp         # 临时文件目录，936MB大小，使用0%，挂载在/tmp
/dev/sda1                    943M   83M  795M  10% /boot        # 启动分区，943MB大小，已使用83MB(10%)，挂载在/boot
/dev/mapper/debian--vg-var   2.2G  725M  1.4G  35% /var         # var目录LVM卷，2.2GB大小，已使用725MB(35%)，挂载在/var
/dev/mapper/debian--vg-srv    20G  2.1M   19G   1% /srv         # srv目录LVM卷，20GB大小，已使用2.1MB(1%)，挂载在/srv
tmpfs                        1.0M     0  1.0M   0% /run/credentials/getty@tty1.service  # tty1服务凭证目录，1MB大小，使用0%
tmpfs                        188M   16K  188M   1% /run/user/0  # root用户临时文件系统，188MB大小，已使用16KB(1%)，挂载在/run/user/0

##lsblk输出解释
NAME                  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda                     8:0    0   30G  0 disk              # 主物理硬盘，30GB大小
|-sda1                  8:1    0  976M  0 part /boot        # 第一个分区，976MB大小，挂载在/boot
|-sda2                  8:2    0    1K  0 part              # 第二个分区，1KB大小，可能是扩展分区
`-sda5                  8:5    0   29G  0 part              # 第五个分区(逻辑分区)，29GB大小，用于LVM
  |-debian--vg-root   254:0    0  5.8G  0 lvm  /            # LVM卷，5.8GB大小，挂载为根目录/
  |-debian--vg-var    254:1    0  2.3G  0 lvm  /var         # LVM卷，2.3GB大小，挂载为/var
  |-debian--vg-swap_1 254:2    0  976M  0 lvm  [SWAP]       # LVM卷，976MB大小，用作交换分区
  `-debian--vg-srv    254:3    0   20G  0 lvm  /srv         # LVM卷，20GB大小，挂载为/srv
sr0                    11:0    1  1.8G  0 rom                # 光驱设备，1.8GB大小

我记得有一次，同事直接就开始扩容，结果发现人家用的是LVM，但他按普通分区的方法搞，折腾了半天。所以这个检查步骤真的很重要。

还有就是备份，虽然扩容一般不会丢数据，但万一呢？我见过因为操作失误导致数据丢失的案例，那个心情...真的是欲哭无泪。云平台的话一定要记得先打个快照！！！

# 简单备份重要数据
tar -czf /tmp/important_data_backup.tar.gz /path/to/important/data

云平台扩容操作

现在大部分服务器都在云上，所以先说说云平台的扩容。各家云厂商的界面不太一样，但基本流程差不多。

阿里云ECS扩容

登录阿里云控制台，找到你的ECS实例，点击"更多" -> "磁盘和镜像" -> "扩容磁盘"。这里有个坑，如果是系统盘扩容，需要重启实例，数据盘可以在线扩容。

扩容完成后，云平台只是给你分配了更大的磁盘空间，但操作系统还不知道，需要我们手动刷新：

# 刷新磁盘信息
echo 1 > /sys/class/block/vda/device/rescan

# 或者使用这个命令
partprobe /dev/vda

腾讯云CVM扩容

腾讯云的操作也类似，在云硬盘控制台选择要扩容的磁盘，点击"扩容"。价格还算合理，就是有时候扩容需要等几分钟。

AWS EC2扩容

AWS的界面相对复杂一些，在EC2控制台找到Volumes，选择要扩容的卷，点击"Modify Volume"。AWS的好处是扩容速度比较快，基本上几秒钟就完成了。

不管哪个云平台，扩容完成后都需要在操作系统层面进行后续操作，这才是重点。

LVM逻辑卷扩容详解

LVM（Logical Volume Manager）是Linux下非常强大的磁盘管理工具，扩容相对简单，而且风险较小。我个人比较推荐使用LVM，特别是生产环境。

检查LVM状态

# 查看物理卷
pvdisplay

# 查看卷组
vgdisplay

# 查看逻辑卷
lvdisplay

我们的系统结构是这样的：

• 物理磁盘：/dev/sda
• 卷组：debian-vg

• 逻辑卷：

  • root
  • srv
  • swap_1
  • var

扩展物理卷

MBR与GPT分区格式对比表（这个需要先知道）

从这个表格可以看出，除非是特殊的兼容性需求，否则GPT在各方面都比MBR有优势。特别是在磁盘扩容场景下，GPT的操作更加灵活方便。

如果云平台已经扩容了底层磁盘（我这边使用虚拟机进行模拟磁盘扩容，简单扩容10G），我们需要先扩展物理卷：

因为分区模式是MBR，所以给5号逻辑分区扩容的话要先给2号扩容了！！！

注意：使用parted命令操作分区是实时保存的！！一定要小心

现在分区5扩容完成：

# 扩展物理卷到磁盘的最大可用空间
pvresize /dev/sda5
# 检查扩展结果
pvs

扩展逻辑卷

# 扩展逻辑卷，增加10G空间
lvextend -L +10G /dev/debian-vg/root

# 或者扩展到卷组的所有可用空间
lvextend -l +100%FREE /dev/debian-vg/root

# 检查扩展结果
lvs

这个命令执行很快，基本上秒完成。但是注意，这时候文件系统还没有感知到空间的增加。

扩展文件系统

这一步是关键，不同的文件系统用不同的命令：

# 对于ext4文件系统
resize2fs /dev/debian-vg/root

# 对于etx4文件系统，需要判断是用什么文件系统，后面跟的是分区路径
resize2fs /dev/mapper/debian--vg-root

# 检查结果
df -h

我遇到过一个奇葩问题，resize2fs执行了很久都没完成，后来发现是磁盘IO性能太差。如果遇到这种情况，可以加个-p参数看进度：

resize2fs -p /dev/debian-vg/root

普通分区直接扩容

如果没有使用LVM，直接对分区进行扩容会复杂一些，而且风险相对较大。

查看分区表

# 查看分区信息
fdisk -l /dev/vda

# 或者使用parted
parted /dev/vda print

删除并重建分区

这个操作听起来很吓人，但实际上只是修改分区表，不会删除数据。不过还是建议先备份重要数据。

# 使用fdisk操作
fdisk /dev/vda

# 在fdisk交互界面中：
# 1. 输入 p 查看当前分区
# 2. 输入 d 删除要扩容的分区（比如分区2）
# 3. 输入 n 创建新分区，起始扇区保持不变，结束扇区选择默认（使用全部空间）
# 4. 输入 w 保存并退出

#我比较喜欢用parted
# 一条命令完成扩容，将所有容量分配到2号分区
parted /dev/vda resizepart 2 100%

这里有个重要提醒，新分区的起始扇区必须和原来一样，否则数据就真的没了。我见过有人手抖输错了起始扇区，结果...

刷新分区表

# 通知内核重新读取分区表
partprobe /dev/vda

# 或者
echo 1 > /sys/class/block/vda/device/rescan

扩展文件系统

# 检查文件系统
e2fsck -f /dev/vda2

# 扩展文件系统
resize2fs /dev/vda2

不同文件系统的扩容方法

Linux支持很多种文件系统，每种的扩容方法都有些差异。

ext4文件系统扩容

ext4是最常见的文件系统，扩容相对简单：

# 在线扩容（推荐）
resize2fs /dev/mapper/debian--vg-root

# 离线扩容（需要先卸载文件系统）
umount /dev/mapper/debian--vg-root
e2fsck -f /dev/mapper/debian--vg-root
resize2fs /dev/mapper/debian--vg-root
mount /dev/mapper/debian--vg-root /

ext4的在线扩容功能很稳定，我用了这么多年基本没遇到过问题。

xfs文件系统扩容

xfs文件系统只支持在线扩容，不能缩小：

# xfs在线扩容
xfs_growfs /

# 如果要指定设备
xfs_growfs -d /dev/mapper/debian--vg-root

xfs的性能比ext4好一些，特别是大文件操作，但是不能缩小这点有时候比较麻烦。

btrfs文件系统扩容

btrfs是比较新的文件系统，功能很强大：

# btrfs扩容
btrfs filesystem resize max /

# 或者指定大小
btrfs filesystem resize +10G /

btrfs支持很多高级功能，比如快照、压缩等，但稳定性还是不如ext4。

zfs文件系统扩容

zfs主要在FreeBSD和Solaris上使用，Linux上也有：

# 扩展zpool
zpool online -e poolname /dev/vda2

# 检查状态
zpool status

zfs的数据保护功能很强，但配置相对复杂。

常见问题和解决方案

扩容后空间没有增加

这是最常见的问题，通常是忘记了扩展文件系统：

# 检查逻辑卷是否已扩展
lvs

# 检查文件系统是否已扩展
df -h

# 如果逻辑卷已扩展但文件系统没有，执行：
resize2fs /dev/mapper/debian--vg-root

分区表类型不支持大容量

MBR分区表最大支持2TB，如果磁盘超过2TB需要转换为GPT：

# 备份分区表
sgdisk --backup=table /dev/vda

# 转换为GPT（危险操作，务必备份）
sgdisk --mbrtogpt /dev/vda

文件系统检查失败

有时候resize2fs会报错，需要先检查文件系统：

# 强制检查文件系统
e2fsck -f /dev/mapper/debian--vg-root

# 如果有错误，修复后再扩容
e2fsck -y /dev/mapper/debian--vg-root
resize2fs /dev/mapper/debian--vg-root

在线扩容失败

某些情况下在线扩容可能失败，需要离线操作：

# 进入单用户模式或使用救援盘
# 卸载文件系统
umount /dev/mapper/debian--vg-root

# 检查并扩容
e2fsck -f /dev/mapper/debian--vg-root
resize2fs /dev/mapper/debian--vg-root

# 重新挂载
mount /dev/mapper/debian--vg-root /

扩容最佳实践

经过这么多年的实践，我总结了一些扩容的最佳实践：

规划先行：在部署系统时就要考虑好磁盘规划，推荐使用LVM，为将来的扩容留下余地。

监控告警：设置磁盘使用率告警，不要等到95%才想起来扩容。我一般设置80%就开始关注，85%就准备扩容。

备份为王：虽然扩容一般不会丢数据，但重要数据一定要备份。我见过太多因为操作失误导致的悲剧。

测试环境先试：生产环境扩容前，最好在测试环境先演练一遍，特别是那些复杂的分区结构。

文档记录：每次扩容都要记录详细的操作步骤和遇到的问题，方便以后参考。

分批操作：如果有多台服务器需要扩容，不要一次性全部操作，万一出问题影响面太大。

写在最后

磁盘扩容看起来复杂，但掌握了基本原理和操作步骤，其实并不难。关键是要理解Linux的存储架构：物理磁盘 -> 分区 -> 物理卷 -> 卷组 -> 逻辑卷 -> 文件系统。

每一层都有对应的扩容操作，从底层到上层依次进行就行。LVM的扩容相对简单安全，普通分区的扩容需要更加小心。

记住几个要点：

• 扩容前一定要备份重要数据
• 了解当前的存储架构再动手
• 云平台扩容只是第一步，还需要操作系统层面的操作
• 不同文件系统的扩容命令不同
• 测试环境先验证，生产环境再操作

最后再强调一遍，重要数据一定要备份！我见过太多因为一个手误导致数据丢失的案例，那种心情真的是...欲哭无泪。

希望这篇文章能帮到遇到磁盘扩容问题的朋友们。运维这条路上坑很多，但只要我们互相分享经验，总能少踩一些坑。

如果你觉得这篇文章对你有帮助，不妨点个赞转发一下，让更多的运维兄弟看到。有什么问题或者更好的方法，也欢迎在评论区讨论。

记住，运维路上我们都是战友，互相帮助才能走得更远！关注@运维躬行录，我会持续分享更多实用的运维技术和经验。

如果这篇文章对你有帮助，别忘了点赞转发支持一下！想了解更多运维实战经验和技术干货，记得关注微信公众号@运维躬行录，领取学习大礼包！！！我会持续分享更多接地气的运维知识和踩坑经验。让我们一起在运维这条路上互相学习，共同进步！

公众号：运维躬行录

个人博客：躬行笔记