Azure 老号 Azure微软云磁盘扩容教程

前言：磁盘不够用时，别慌，先深呼吸再扩容

在 Azure 上跑着跑着，突然发现磁盘空间告急：日志爆满、数据越堆越多、备份越来越沉，连“还剩多少 GB”这种问题都能把人逼出汗。你可能会想：是不是要重建虚拟机？是不是要找运维大神救场？别急，今天这篇《Azure微软云磁盘扩容教程》就把从“云端先把盘变大”到“系统里把分区吃饱”的整套流程讲清楚。

你会看到：操作其实并不神秘，关键在于“别只扩云端不扩系统”，也别只扩系统但云端容量没变。很多坑就卡在这里：扩完云盘才发现系统没跟上；或者系统扩了但分区表不认；或者重启后才发现自己漏了某个步骤。我们把这些都提前预警。

扩容前的准备工作（不做会怎样？一般会怎样）

先说结论：在扩容之前，至少做四件事。它们看起来“繁琐”，但实际可以帮你避免返工、避免数据焦虑。

1）确认你要扩的是系统盘还是数据盘

系统盘：承载操作系统与启动相关文件。数据盘：承载业务数据。两者在“你要不要重启”“扩容后应用是否有影响”方面略有差异。

如果你不确定：通常可以在 Azure 门户的虚拟机页面里看到磁盘列表，并查看磁盘挂载路径、LUN、以及是否标记为操作系统磁盘。

2）确认磁盘是否是托管磁盘（Managed Disk）

大部分现代 Azure 虚拟机都使用托管磁盘。托管磁盘扩容方式相对标准：在门户或使用命令修改磁盘大小即可。

如果你正在使用托管磁盘，恭喜，后面的流程基本就按“常规套路”来。

3）检查当前分区与文件系统类型

你需要知道操作系统里分区怎么划的，以及文件系统是什么类型：Windows 常见 NTFS；Linux 常见 ext4/xfs。扩容分区后，文件系统也要相应扩展。

尤其是 Linux 的 LVM 情况：如果你用的是 LVM，就要先扩物理卷/卷组/逻辑卷再扩文件系统。这部分我也会给出思路。

4）备份与告知相关人员（至少做个心理安稳版）

扩容一般不会破坏数据，但“万一”永远是人类的天赋。建议在扩容前做备份，或至少确认你能快速回滚/恢复。对生产环境，提前告知业务同事：可能会有短暂的维护窗口，尤其涉及重启或服务重启。

第一步：在 Azure 里把云盘扩容（让天空先变大）

把云盘扩容这一步做完，你的虚拟机“看到”的磁盘容量才会发生变化。否则后面系统里扩分区会变成“你明明没变大，我怎么能扩”的尴尬剧情。

方式一：Azure 门户操作步骤（适合大多数人）

下面按常见界面描述，尽量不让你在页面里迷路。

1. 登录 Azure 门户。
2. 进入“虚拟机”列表，选择目标虚拟机。
3. 在虚拟机页面找到“磁盘”或“磁盘”相关选项，查看附加的磁盘列表。
4. 选择你要扩容的那个磁盘（注意区分：操作系统磁盘 vs 数据磁盘）。
5. 找到磁盘属性页中的“大小”或“磁盘大小”字段。
6. 将磁盘大小从当前容量调整为更大的容量。
7. 保存更改。

保存后，一般不需要立刻重启虚拟机（但有的场景可能需要），尤其在云端扩容托管磁盘后，系统端可能需要重新扫描磁盘。

方式二：命令思路（喜欢自动化的人用得上）

Azure 老号 如果你在做批量扩容，命令行更合适。通常思路是：通过 Azure CLI 或 PowerShell，修改目标托管磁盘的大小字段。

不过不同环境参数会有差异（订阅、资源组、磁盘名等）。你可以把门户里的“磁盘资源名称”记下来，再在命令里对应填入。

Azure 老号 你不想背命令也没关系：先用门户成功扩一次，把“变量”弄清楚；之后再把同样的变量交给脚本，效率直接起飞。

第二步：让虚拟机系统“识别到新容量”（系统端不相信云端怎么办？）

云端扩容完，下一步就是在虚拟机内部让操作系统重新识别磁盘大小。不同系统的操作略有不同。

Windows：重新扫描磁盘（通常不用重启）

Windows 下可以这样做：

1. 打开“磁盘管理”（Disk Management）。
2. 右键磁盘管理窗口中的“磁盘/卷列表”，选择“重新扫描磁盘”。（不同 Windows 版本显示项可能略有差异）
3. 查看目标磁盘是否出现“未分配空间”或分区大小是否已经更新。

如果你扩容后磁盘管理里还是“看起来没变”，你可以尝试：重启虚拟机或在设备管理器/磁盘控制器处触发重新扫描。

Linux：触发 SCSI/块设备重扫描（让内核更新视图）

Linux 常见场景是：你扩容了云端磁盘，但内核仍缓存了旧容量，需要刷新。

你可以尝试几种常见方法（不需要你全会，但至少知道怎么找）：

1. 检查当前块设备：使用 lsblk 查看磁盘分区。
2. 尝试触发重扫描：例如通过 echo 某些值到 /sys 路径，或通过 rescan-scsi-bus（取决于发行版与内核配置）。
3. 确认容量变化后再扩分区。

重点是：不要急着改分区表。先确保 lsblk 能看到更大的磁盘容量，再进行后续扩容。

第三步：扩容分区（让空间真正落地）

云盘变大≠分区变大。你需要在操作系统里把“分区边界”往外挪，让分区包含新增长的未分配空间。

Windows：扩展卷（Extend Volume）

常见流程：

1. 打开“磁盘管理”。
2. 找到目标分区（例如 D:、E: 等）。
3. 确保分区右侧或相关位置有“未分配空间”（Unallocated）。
4. 右键目标分区，选择“扩展卷（Extend Volume）”。
5. 选择要扩展的容量（默认通常会把可用未分配空间都吞掉）。
6. 完成向导，确认新卷大小生效。

如果你看不到“未分配空间”，可能原因包括：分区本身占满了磁盘；或者磁盘布局与预期不一致。此时需要检查分区表、LUN 映射、或你是否扩错了磁盘。

Linux：扩分区（parted / growpart / fdisk）

Linux 下扩分区常见工具：

• 如果使用的是 GPT 或常规分区，且分区紧贴磁盘末尾：可以使用 growpart 直接增长分区。
• 或者用 parted 修改分区边界。
• 必要时使用 fdisk 重新写入分区（注意：这类操作要特别谨慎，别乱动起始扇区）。

原则只有一个：你要“扩大分区的末端”，一般不要改动分区起始位置（否则可能导致数据不可用）。

扩分区后，文件系统还没自动变大。你得继续下面一步。

第四步：扩展文件系统（空间能用，才算真扩了）

到这里很多人会以为“我已经把分区扩了，文件系统应该自动跟着变”，然后它就给你来一句“nope”。不同文件系统需要不同命令或操作。

Windows：通常无需额外手动（但检查一下更安心）

在 Windows 的“扩展卷”向导中，通常会同时完成文件系统识别。扩完后，直接在资源管理器里看盘符容量是否上涨即可。

如果容量没有增长，建议回到磁盘管理重新确认未分配空间是否被分区正确吞掉。

Linux：ext4 文件系统扩展

对于 ext4，常见做法是使用 resize2fs：扩展到设备大小。

思路是：先确定目标分区（例如 /dev/sdb1），然后对文件系统执行扩展操作。执行成功后，用 df -h 看挂载点空间是否增加。

Linux：XFS 文件系统扩展

XFS 的特点是：扩展通常可以在挂载状态下进行。常见命令是 xfs_growfs，通常输入的是挂载点。

同样，用 df -h 验证结果。

如果你用的是 LVM：扩容就像“套娃”，一步都不能少

很多生产 Linux 会用 LVM（逻辑卷管理），因为它能让扩容更灵活。LVM 扩容看起来更复杂，但思路清晰：扩“物理卷”→扩“卷组”→扩“逻辑卷”→扩文件系统。

典型步骤概念（不绑定你具体环境，但让你不迷路）

1. 让系统看到新容量（已在前面做过重扫描与扩分区）。
2. 扩展物理卷（PV）：把新的分区容量加入 PV。
3. 扩展卷组（VG）：让 VG 吃到新增 PV 的空间。
4. 扩展逻辑卷（LV）：把 LV 的大小扩大。
5. 扩展文件系统：ext4 用 resize2fs，xfs 用 xfs_growfs。

如果你在这段读着“感觉像在听天书”，也没关系：你至少要记住顺序。LVM 的错误往往不是“命令不会”，而是“扩容顺序错了导致后续找不到空间”。

常见坑位与排查清单（扩容时最常见的那些翻车瞬间）

下面这部分很重要，因为真实世界里最常见的不是“完全不会”，而是“差一步就差到你怀疑人生”。

坑 1：云端扩了，但系统里分区没变化

原因：你只改了 Azure 磁盘大小，没有在虚拟机内扩分区/文件系统。

解决：按照本文的第二、三、四步走一遍。重扫描磁盘、扩分区、再扩文件系统。

坑 2：扩分区时提示没有未分配空间

原因：分区可能不是紧贴磁盘尾部；或者你扩错了磁盘/LUN；或者磁盘分区布局导致扩展不可直接完成。

解决：先核对挂载关系（Azure 磁盘到系统设备映射），再核对分区表与未分配空间位置。

坑 3：分区扩了但 df 显示还是旧容量

原因：文件系统未扩展。

解决：对 ext4/xfs 等做对应的文件系统扩展命令或在 Windows 上确认向导是否完成。

坑 4：扩完需要重启吗？到底要不要重启

多数情况下，Windows 扫描磁盘即可，Linux 通过重扫描即可。但某些环境、某些驱动/版本可能需要重启才能让系统完全识别新容量。

判断方法：扩完云端后先尝试重扫描；如果磁盘容量仍旧不变，再考虑重启。

坑 5：权限不足或命令运行失败

Linux 上执行调整分区和文件系统通常需要 root 权限。Windows 上执行扩展卷可能需要管理员权限。

解决：确保你使用了有权限的账号，并查看命令输出的错误信息。

最佳实践：怎么做得更稳、更省心

你当然可以“按教程点完就结束”，但更好的做法是把扩容流程变成可复用的“操作模板”。

1）先在测试环境验证同样的扩容链路

如果你有相似配置的测试虚拟机，先扩一次。确认后再在生产执行。

2）记录当前分区与挂载信息

扩容前，把关键信息保存一下，比如：

• 设备路径与分区编号（Linux：/dev/sdb1 这种）
• 挂载点（/var、/data 等）
• 文件系统类型（ext4/xfs）
• 分区表类型（GPT/MBR）

这样你后面排查会快很多。

3）扩容尽量一次到位，别频繁来回拉扯

每次扩容都意味着一次维护与一次风险。你可以评估业务增长，给磁盘留出冗余空间，而不是刚扩完就又报警。

示例场景：一次“从告警到搞定”的完整演示（概念版）

假设你的 Azure 虚拟机上，数据盘快满了。你希望把数据盘从 256GB 扩到 512GB。

1. 进入 Azure 门户，找到这台虚拟机的“数据磁盘”，把磁盘大小从 256GB 改为 512GB，保存。
2. 回到虚拟机操作系统：Windows 打开磁盘管理，重新扫描；Linux 先用 lsblk 确认磁盘容量已变大。
3. Azure 老号 扩分区：Windows 右键分区选择“扩展卷”；Linux 用 growpart/parted 将分区末端扩大到可用空间。
4. Azure 老号 扩文件系统：Windows 通常自动完成；Linux 用 resize2fs（ext4）或 xfs_growfs（xfs）。
5. 最后验证：用资源管理器或 df -h 检查挂载点容量是否增加。

完成后，业务日志可以继续放肆，监控也不再天天“尖叫”，你也能在同事追问时说一句：放心，已经吃饱了。

结尾：把扩容当成一项“熟练技能”，你会越来越从容

Azure 的磁盘扩容，本质上就是一个链路：云端盘变大 → 系统识别新容量 → 分区扩展 → 文件系统扩展 → 验证生效。只要每一步都做对，扩容就不会变成玄学。

如果你愿意，我也可以根据你的具体情况把流程进一步“对号入座”。你可以告诉我：你是 Windows 还是 Linux？扩的是系统盘还是数据盘？文件系统是 NTFS/ext4/xfs？有没有用 LVM？我就能给你更贴近你环境的操作清单。