7个扩容坑别踩！硬盘避坑指南帮你省心省力

昨天接了个既简单又有点门道的远程支持。一位粉丝用户向我求助，希望我帮忙处理服务器磁盘扩容的问题。原本以为只是常规操作，我爽快答应了。

他的操作系统是CentOS7，/data分区已经100%占满。更要紧的是，MySQL和PostgreSQL数据库都挂在这块盘上，业务连接也已经中断。

但奇怪的是，这块云硬盘实际上是2.5T容量，当前仅部署了1T空间。运维同事刚好不在岗，需要远程协助完成扩容。

考虑到是远程操作存在风险，我让用户先通过云平台为这台服务器创建快照，并手动备份关键数据。这个预防措施非常必要。

作为运维工程师，这种磁盘爆满的情况早已司空见惯。登录服务器后，我首先确认磁盘使用情况：

df -h /data

输出结果显示：

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdb1       985G  935G    0  100% /data

果然已经100%占满。这是一块2.5TB的云硬盘，按理说空间应该很充足才对。

1. 首次扩容遭遇异常

我熟练地执行了标准的扩容命令：

growpart /dev/vdb 1

然而，等到的不是成功提示，而是一串报错信息：

正常情况下，执行这条命令后，/dev/vdb的所有剩余空间应该扩展到/dev/vdb1分区。但现在出现了报错，似乎是分区表存在冲突，还提示有数据丢失风险，顿时让我认真了起来。

2. 深入排查发现问题

接下来，我开始仔细排查。首先查看磁盘的详细信息：

fdisk -l /dev/vdb

输出结果令人惊讶：

再用parted工具确认：

parted /dev/vdb print

问题主要在三个方面： - 磁盘实际大小为2.5T，但只划分了1T的分区 - 分区表是GPT类型（正确，因为大于2TB） - 文件系统只格式化了985G，没有占满整个1T分区

但为什么我执行growpart /dev/vdb 1会失败呢？询问用户具体情况，他似乎也不太清楚。我总结了可能的原因：

可能之前有人在大于2TB的磁盘上尝试使用MBR分区表，后来发现无法使用全部空间，又创建了GPT分区表但没有正确清理旧的MBR信息，导致两者并存，变成了一个"混合式"的分区表，既有GPT信息，又有非保护性的MBR信息。

3. 解决方案与操作步骤

由于是ext4文件系统，不支持在线扩容空间。既然growpart已经不可行，我就换成parted来处理。根据规范，扩容前需要先卸载分区，获得用户同意后开始恢复操作。

首先是卸载分区：

umount /data

但系统提示：

umount: /data: target is busy.

这意味着有进程正在使用这个目录。需要用以下命令找出相关进程：

lsof /data

发现很多MySQL文件还占用着这个目录，应该是异常中断后，有些进程没有完全退出。我用ps -ef | grep mysql命令找到MySQL进程，然后用kill -9 PID强制终止后，成功卸载/data分区。

卸载成功后，按顺序执行以下步骤：

# 文件系统检查（强烈推荐！）
e2fsck -f /dev/vdb1
# 扩容分区至磁盘末尾
parted /dev/vdb resizepart 1 100%
# 刷新系统分区表信息
partprobe /dev/vdb
# 扩容文件系统
resize2fs /dev/vdb1
# 重新挂载（如果系统启动了自动挂载，可不执行）
mount /dev/vdb1 /data

最后验证扩容结果：

df -h /data

lsblk  /dev/vdb

整个磁盘扩容过程顺利完成。

4. 技术要点总结与建议

MBR与GPT选择：大于2TB的磁盘必须使用GPT分区表

分区与文件系统：分区大小和文件系统大小是两回事。我平时不喜欢将数据盘再进行分区，直接格式化来用，这样扩容更容易。

操作前先诊断：知其然更要知其所以然。我开始就犯了个小错误，上来就扩容，没有先搞清楚具体情况。

读懂错误信息：错误信息往往包含了解决方案的线索

备份是最后的防线：我一上来就让用户打个快照和备份，必要时进行回滚。

最后想说的是：赚点钱不容易，操作需谨慎，别把自己也搭进去了！