服务商控制台里，磁盘已经从 100GB 调到了 200GB，登录 Linux 执行 df -h，文件系统容量却还是原来的数字。这是数据盘扩容时最常见的困惑。

原因在于，云平台提供的磁盘容量、操作系统识别到的块设备容量、分区大小和文件系统可用空间，是不同层次的概念，必须按实际的磁盘结构逐层处理，新增空间才能用上。先说明一点：分区和文件系统操作可能影响数据，动手之前务必完成备份并核对设备名称，下文的命令都是示例，设备名要按自己机器上的实际结果替换。

扩容之前，先判断 Linux 服务器使用哪种磁盘结构

第一类：数据盘独立存在，尚未建立分区或文件系统

这类磁盘和已有分区的扩容不是一回事，要先识别上面有没有数据，再决定分区、建文件系统和挂载。初始化新盘的操作，严禁用在已有数据的磁盘上。

第二类：数据盘已经分区，并创建了文件系统

这是最常见的扩容场景。底层磁盘扩大后，要检查分区是不是还停留在原来的大小，文件系统是否也需要继续扩展。

第三类：使用 LVM 逻辑卷管理

LVM 里的物理卷、卷组、逻辑卷和文件系统，各有各的容量边界。只扩大底层磁盘，往往还得调整物理卷和逻辑卷，再扩展文件系统，具体顺序看当前结构。

第四类：系统盘与数据盘的操作方式不同

系统盘存放操作系统和引导相关内容，分区改错了，服务器可能起不来。数据盘虽然独立，也不能因此跳过备份和设备核对。

第一步，确认当前磁盘、分区和文件系统

使用 lsblk 查看设备结构

lsblk 和 lsblk -f 可以列出磁盘、分区、文件系统类型和挂载点：

lsblk

lsblk -f

设备名称可能是 /dev/vda、/dev/sdb，也可能是 NVMe 形式的 /dev/nvme1n1，不能默认所有服务器都一样。

使用 df -hT 检查文件系统空间

df -hT

df -hT 看的是已挂载文件系统的容量、已用、可用和类型。它反映的是文件系统层面的使用情况，和服务商分配的整块磁盘容量对不上，往往说明还差一步没做。

检查是否使用 LVM 与具体文件系统

根据 lsblk 和 df -hT 的结果，判断有没有涉及 LVM，文件系统是 ext4、XFS 还是别的类型。设备名称、分区编号或文件系统类型不清楚时，不要执行任何扩容命令。

第二步，在云服务器控制台完成底层磁盘扩容

先确认当前产品是否支持在线扩容

核对能不能直接加容量、有没有最小扩容单位、要不要停止实例、有没有容量上限。这些规则因平台和产品而异，别把某一家的流程当成统一标准。

扩容前先完成数据保护

至少确认重要数据已备份，并核实备份能恢复。数据库和持续写入的业务，还要按业务要求安排一致性备份或维护窗口，别只复制某一时刻不一致的文件。

确认控制台已经完成容量调整

先看任务状态，再到 Linux 里确认块设备识别到的容量有没有变化。系统仍没识别到新容量的话，按平台的官方流程排查，别直接去动分区表。

第三步，按实际文件系统和分区类型执行扩容

下面分情况讲，每种情况都有适用条件。示例以 /dev/vdb 为整块数据盘、/dev/vdb1 为它的第一个分区，设备名和分区编号请按 lsblk 的实际结果替换。

场景一：普通分区加 ext4 文件系统

适用条件：底层磁盘已扩容，数据盘上只有一个分区，文件系统是 ext4。通常先扩展分区，再调整文件系统：

sudo growpart /dev/vdb 1

sudo resize2fs /dev/vdb1

growpart 把分区扩到磁盘末尾，注意磁盘名和分区号之间有空格；resize2fs 再扩展 ext4 文件系统。

场景二：普通分区加 XFS 文件系统

适用条件：分区已扩大，XFS 文件系统已挂载。XFS 的流程和 ext4 不完全一样，针对的是挂载点，不是设备路径：

sudo xfs_growfs /data

/data 是示例挂载点。先用 df -hT 核对文件系统类型，别把 ext4 的命令套到 XFS 上。

场景三：LVM 逻辑卷扩容

可以按下面的层次来：

1. 识别磁盘、分区与 LVM 结构

2. 确认新增容量已被底层设备识别

3. 按当前结构决定是否先扩展分区与物理卷

4. 扩展逻辑卷，并确认文件系统是否同时扩展

5. 重新检查容量、挂载状态和应用读写

常用工具是 pvresize 和 lvextend，卷组名和逻辑卷名要按 pvs、vgs、lvs 的结果替换：

sudo pvresize /dev/vdb1

sudo lvextend -r -l +100%FREE /dev/vg_data/lv_data

-r 参数会在扩展逻辑卷的同时调整文件系统。

场景四：新增一块独立数据盘

新增磁盘用另一套流程：

确认新磁盘的设备名称，以及上面是否已有数据

按用途规划分区和文件系统

挂载到目标目录

设置所需的目录权限

验证应用和服务能否正常读写

初始化空白磁盘和扩容已有数据盘是两类操作，不能混用。创建文件系统的 mkfs 会清除分区上的数据，只能用在确认为空的新盘上。

第四步，挂载数据盘并确保重启后仍然生效

为什么手动挂载后，重启服务器可能丢失挂载状态？

只执行一次 mount，挂载关系只在当前运行期间有效，重启后系统不一定会把同一块磁盘挂到预期位置。

使用 UUID 规划持久化挂载

先获取文件系统的 UUID，再写进 /etc/fstab。用 UUID 不依赖设备名，因为设备名在重启或增减磁盘后可能变化：

sudo blkid /dev/vdb1

UUID=xxxx-xxxx  /data  ext4  defaults,nofail  0  2

第二行是 /etc/fstab 里的一条示例，UUID 和文件系统类型要换成自己的。修改前先备份，改完用 sudo mount -a 检查有没有报错，确认没问题再考虑重启，配置错误可能影响系统启动。nofail 能让磁盘缺失时不阻塞启动，是否适用看业务。

挂载完成后，检查目录权限和应用路径

数据库、Web 文件、日志和上传目录，可能需要不同的所有权和权限。应用数据迁到新挂载点的话，还要核对应用配置和启动顺序，避免服务启动时数据盘还没挂载。

第五步，如何判断扩容已经成功？

可以按这份验收清单逐项确认：

1. 用 lsblk 确认块设备和分区大小

2. 用 df -hT 确认文件系统可用空间

3. 检查文件系统与挂载状态是否符合预期

4. 权限允许的情况下，做一次受控读写测试

5. 检查应用日志与数据库状态

6. 按计划验证重启后的挂载行为

7. 保留变更记录与必要的备份信息

容量还是没变化，先确定问题出在底层设备、分区、逻辑卷、文件系统还是挂载路径，再按层次排查。

数据盘扩容时，哪些操作最容易造成数据风险？

设备名称认错，导致操作落到错误磁盘

这是最需要警惕的风险。执行分区命令之前，必须对照 lsblk 的结果确认目标，不要凭示例去猜实际的设备名。

跳过备份，直接修改已有数据盘

分区表和文件系统的变更有风险，业务持续写入时直接操作更危险，动手前要有数据保护。

只扩展了底层磁盘，没有完成文件系统调整

这种情况下，操作系统看到的磁盘容量和 df 显示的文件系统容量对不上，新增空间用不了。

修改 /etc/fstab 后没有验证

挂载配置写错了，重启后可能挂载失败，甚至启动异常。改完先做检查，确认有效之前，别贸然重启生产服务器。

恒讯科技国外云服务器的数据盘扩容，需要提前确认什么？

恒讯科技公开的服务器配置资料涉及磁盘容量和硬件升级等事项。扩容前要确认产品能力，扩容后要完成系统侧的操作，可以逐项确认：

当前产品是否支持增加现有磁盘容量，或加装独立数据盘

扩容是否需要关机，磁盘类型与容量有没有限制

提前安排备份，并确认数据盘当前的分区、文件系统和挂载方式

扩容完成后，按 Linux 的实际环境执行分区或文件系统调整

业务数据库和生产文件，先制定恢复方案再变更

具体机型是否支持无停机扩容，以产品说明和服务商确认为准。可以先从 全球服务器列表 了解产品。

常见问题

1. 国外云服务器控制台已经扩容，为什么 Linux 仍显示原来的磁盘大小？

控制台扩的是底层磁盘，分区和文件系统还要在系统里继续调整，先用 lsblk 看是否识别到新容量。

2. ext4 和 XFS 的扩容步骤一样吗？

不一样。ext4 通常用 resize2fs 针对设备扩展，XFS 用 xfs_growfs 针对挂载点扩展，要先核对文件系统类型。

3. 数据盘扩容是否一定需要重启服务器？

不一定。是否需要关机或重启，取决于云平台、磁盘类型和系统环境，扩容前向服务商确认。

4. 新增磁盘后，为什么重启服务器就无法找到原来的挂载目录？

多半是只做了临时挂载，没写入 /etc/fstab，或者 UUID、文件系统类型写错了。

5. LVM 逻辑卷扩容与普通分区扩容有什么区别？

LVM 多了物理卷、卷组和逻辑卷几层，要按结构依次扩展；普通分区只有分区和文件系统两层。

6. 扩容前是否一定要备份？如果没有足够空间，应该怎样安排备份？

建议一定要备份。本机空间不够，可以备份到其他服务器或对象存储，并验证能恢复。

扩容的顺序可以记成：先确认磁盘结构，再扩展底层容量，最后调整分区和文件系统，每一步都要对得上实际的设备和文件系统。

咨询“Linux 数据盘扩容与存储规划”时，可以提供操作系统、磁盘结构、当前与目标容量、文件系统类型和能否停机；涉及生产数据库的，先完成备份和恢复验证。