一、高效将实例A的EBS卷迁移至实例B的步骤 #

下面是一套流畅且风险可控的迁移流程，分场景处理根卷和非根卷：

• 准备阶段（降低风险）
  • 若要迁移根卷：必须先停止实例A；若迁移非根卷，可在线操作，但建议先给目标卷创建快照（控制台右键卷→创建快照），防止数据意外丢失。
  • 确认实例B的状态：根卷迁移需要实例B处于已停止状态；非根卷迁移实例B可以是运行中或停止状态。
• 分离实例A的EBS卷
  • 登录AWS EC2控制台，找到实例A，切换到「存储」标签，选中要分离的卷。
  • 右键选择「分离卷」，确认操作后等待卷状态变为「可用」。
• 挂载至实例B
  • 非根卷挂载：找到状态为「可用」的目标卷，右键选择「附加卷」，选择实例B，输入设备名（比如/dev/sdf，AWS会自动映射为nvme设备），确认附加。
  • 根卷挂载：停止实例B，分离它原有的根卷，再将从A分离的根卷附加到实例B，设备名必须选/dev/sda1（根卷默认设备名），之后启动实例B。
• 验证迁移结果
  • 启动实例A（若之前停止），登录实例B，执行lsblk或df -h查看卷是否成功关联；非根卷需要手动挂载（或配置自动挂载）后才能访问数据。

二、解决EBS卷挂载错误的问题 #

看了你给出的命令输出和错误提示，问题其实很清晰——你尝试挂载的是整个磁盘设备/dev/nvme1n1，但实际存储数据的是它下面的分区/dev/nvme1n1p1，直接挂载磁盘肯定会报错。

具体错误分析 #

从lsblk -f的输出能明显看到：

NAME FSTYPE LABEL UUID MOUNTPOINT
nvme0n1 
└─nvme0n1p1 ext4 cloudimg-rootfs e4e7b145-d90a-4248-b083-e6790a0e48fb /
nvme1n1 
└─nvme1n1p1 ext4 cloudimg-rootfs 813a48d1-3b8f-4bf1-b007-d36d47665949

nvme1n1是裸磁盘，没有文件系统标识，而它的子分区nvme1n1p1才是格式化好的ext4分区，这就是挂载失败的核心原因。

修复步骤 #

1. 先确认分区的文件系统（执行这个命令更准确）：

   sudo file -s /dev/nvme1n1p1
   

   输出会显示这是一个ext4文件系统，验证分区的可用性。
2. 挂载分区到/data目录：

   sudo mount /dev/nvme1n1p1 /data
   

3. 验证挂载结果：

   df -h /data
   

   能看到/data对应的磁盘空间，就说明挂载成功了。
4. （可选）设置开机自动挂载
   如果希望重启实例后卷依然自动挂载，需要配置/etc/fstab：
   • 从lsblk -f里复制nvme1n1p1的UUID（比如上面的813a48d1-3b8f-4bf1-b007-d36d47665949）
   • 编辑fstab文件：

     sudo nano /etc/fstab
     

   • 添加以下内容（替换成你的UUID）：

     UUID=813a48d1-3b8f-4bf1-b007-d36d47665949 /data ext4 defaults 0 2
     

   • 保存退出后，执行sudo mount -a验证配置是否正确，没有报错就完成了。

内容的提问来源于stack exchange，提问作者kc7