AWS EBS 磁盘扩容与挂载实验手册
本文档帮助你快速理解 EBS 扩容和挂载新卷的区别，并通过动手实验掌握操作。
核心概念
直接扩 EBS vs 挂载新卷
| 直接扩 EBS | 挂载新卷 | |
|---|---|---|
| 盘的数量 | 还是 1 块 | 变成 2 块 |
| 空间在哪 | 原来的/直接变大 | 在一个新目录下，比如/data |
| 原有程序 | 不用改，路径没变 | 如果程序写/下，用不到新盘空间 |
| 操作复杂度 | 简单（growpart + resize） | 要格式化、挂载、配 fstab |
| 冷却限制 | 改完要等 6 小时才能再改 | 没限制，随时可以挂新盘 |
| 适用场景 | 根分区不够用 | 想把日志、数据库等单独放一块盘 |
扩容三层结构
EBS 卷（硬件层）：控制台修改大小 └─ 分区（OS层）：growpart 扩展分区边界 └─ 文件系统：resize2fs/xfs_growfs 让系统识别新空间控制台只能管"硬件"这一层，分区和文件系统是操作系统内部的事，需要进服务器手动扩展。
文件系统类型判断
df -Th /ext4（常见于 Ubuntu/Debian）→ 用sudo resize2fs /dev/xvda1xfs（常见于 Amazon Linux/RHEL）→ 用sudo xfs_growfs /
lsblk 输出解读
xvda 20G disk ← 整块磁盘 ├─xvda1 8G part / ← 根分区，数据都在这 ├─xvda127 1M part ← BIOS Boot 分区，GRUB 引导代码，不用管 └─xvda128 10M part /boot/efi ← UEFI 启动文件，不用管xvda127 和 xvda128 编号放在最后面，是 AWS 故意的设计，保证 xvda1 可以顺畅向后扩展。
设备名对应关系
控制台填的名字和服务器里看到的可能不同：
| 控制台填的 | 服务器里实际显示的 |
|---|---|
| /dev/sdf | /dev/xvdf |
| /dev/sdg | /dev/xvdg |
| /dev/sdp | /dev/xvdp |
指向同一块盘，只是命名方式不同。
实验一：直接扩容 EBS（原盘变大）
前提
- 一台 EC2 实例（t2.micro，Amazon Linux 2023，根盘 8G gp3）
- 记住实例所在可用区
步骤 1：准备测试数据
# SSH 连接后记录初始状态 df -h lsblk # 创建测试文件（验证扩容后数据不丢失） echo "扩容前的数据，如果还在说明扩容成功" > /home/ec2-user/test.txt cat /home/ec2-user/test.txt步骤 2：打快照备份
- EC2 控制台 → Elastic Block Store → Volumes
- 选中根卷 → Actions →Create Snapshot
- 描述填"扩容前备份"
- 等待状态变为Completed
步骤 3：控制台扩 EBS 卷
- Volumes → 选中根卷 → Actions →Modify Volume
- Size 从 8 改为20
- 确认修改
- 等状态从
modifying→optimizing→ 完成
步骤 4：服务器内扩展分区和文件系统
# 确认盘变大了但分区没变 lsblk # 预期：xvda 显示 20G，xvda1 还是 8G # 扩展分区 sudo growpart /dev/xvda 1 # 确认文件系统类型 df -Th / # 扩展文件系统（xfs 的情况） sudo xfs_growfs / # 如果是 ext4 则用： # sudo resize2fs /dev/xvda1 # 验证结果 df -h lsblk # 确认数据还在 cat /home/ec2-user/test.txt预期结果
- 根分区从 8G 变为 20G
- test.txt 内容完好
- 全程无需停机
实验二：挂载新卷（多加一块盘）
前提
使用同一台 EC2 实例
步骤 1：控制台创建新卷
- EC2 → Elastic Block Store → Volumes →Create Volume
- 大小：5G，类型：gp3
- 可用区必须和 EC2 实例一致
- Create Volume
步骤 2：挂载到实例
- 选中新卷 → Actions →Attach Volume
- 选择你的实例
- 设备名自动填（如
/dev/xvdf） - Attach
步骤 3：服务器内操作
# 确认新盘出现 lsblk # 预期看到： # xvda 20G # ├─xvda1 20G / # xvdf 5G ← 新盘，没有挂载点 # 格式化新盘（仅第一次，会清空数据） sudo mkfs.xfs /dev/xvdf # 创建挂载目录 sudo mkdir /data # 挂载 sudo mount /dev/xvdf /data # 验证 df -h # 预期看到 /dev/xvdf 5G 挂载在 /data # 写入测试数据 echo "这是新盘的数据" > /data/newdisk_test.txt cat /data/newdisk_test.txt步骤 4：配置开机自动挂载（可选）
# 获取 UUID sudo blkid /dev/xvdf # 编辑 fstab（注意替换为实际 UUID） sudo bash -c 'echo "UUID=你的UUID /data xfs defaults,nofail 0 2" >> /etc/fstab' # 验证 fstab 配置正确（不会导致启动失败） sudo umount /data sudo mount -a df -h⚠️ 如果不配 fstab，重启后挂载会丢失，需要重新 mount。
预期结果
- 多了一块 5G 独立磁盘
- 挂载在
/data目录 - 根分区
/和新盘/data是独立的
实验三：快照恢复（模拟故障回滚）
前提
已完成实验一（有一个扩容前的快照）
步骤 1：模拟故障
# 写入一些"坏数据" echo "这是扩容后产生的坏数据" > /home/ec2-user/bad.txt步骤 2：停止实例
EC2 → Instances → 选中实例 → Instance State →Stop
等状态变为 Stopped
步骤 3：从快照创建新卷
EC2 → Snapshots → 选中快照 → Actions →Create Volume from Snapshot
- 可用区：必须和实例一致
- 大小：默认（8G，和快照一样）
- Create
步骤 4：替换根盘
- 卸载当前根盘：Volumes → 选中 20G 根卷 → Actions →Detach Volume
- 挂载恢复卷：选中从快照创建的 8G 新卷 → Actions →Attach Volume
- Instance：选你的 EC2
- Device：填
/dev/xvda（必须和原来一致）
步骤 5：启动并验证
Instance State →Start
# SSH 连接后验证 df -h lsblk # 预期：根分区回到 8G cat /home/ec2-user/test.txt # 预期：扩容前写的数据还在 cat /home/ec2-user/bad.txt # 预期：No such file（因为回滚到快照时间点）预期结果
- 根分区恢复到 8G（快照时的状态）
- 快照前的数据（test.txt）完好
- 快照后的数据（bad.txt）不存在
- 相当于"一键回档"
注意事项
| 事项 | 说明 |
|---|---|
| 扩容前打快照 | 养成习惯，操作失误可回滚 |
| 两次修改间隔 | 同一 EBS 卷修改后需等至少 6 小时才能再改 |
| 只能扩不能缩 | EBS 卷只能增大，无法缩小 |
| 不需要停机 | gp2/gp3 扩容支持在线操作 |
| 快照恢复需停机 | 替换根盘必须先 Stop 实例 |
| 可用区一致 | 创建卷/恢复快照时 AZ 必须和实例一致 |
| 扩分区 ≠ 改分区 | growpart 只是把分区终点往后推，数据不动 |
清理资源（避免持续计费）
1. 卸载新卷：sudo umount /data 2. 控制台 Detach 额外的卷 3. Delete 不需要的卷 4. Delete 不需要的快照 5. Terminate EC2 实例（勾选了 Delete on Termination 会自动删根盘）总结
- 根分区空间不够→ 直接扩 EBS，一条路走到底
- 想把某个目录独立出去→ 挂载新卷
- 操作前永远先打快照→ 出问题 5 分钟回滚