Azure：恢复加密Ubuntu 16虚拟机数据磁盘失败求助

这种加密数据盘挂载失败的情况我之前在处理Azure虚拟机恢复时碰到过好几次，咱们一步步来排查解决：

1. 先确认加密磁盘的密钥是否正确加载 #

因为你的数据盘是用BEK+KEK加密的，首先得确保密钥已经正确解密磁盘：

• 执行cryptsetup luksDump /dev/sdb，查看输出里的密钥槽信息，如果能看到已激活的密钥槽，说明磁盘的LUKS加密结构是正常的（Azure加密VM的数据盘默认用LUKS）
• 用lsblk -f检查/dev/sdb的状态，看是否已经生成了加密映射卷（比如/dev/mapper/xxx这类设备），如果没有，说明密钥还没正确关联

2. 修复可能损坏的文件系统（针对bad superblock报错） #

报错里提到的bad superblock大概率是恢复过程中文件系统受损，咱们用备份超级块来修复：

• 先找到备份超级块的位置（以ext4为例，其他文件系统类似）：

  dumpe2fs /dev/sdb1 | grep -i superblock
  

• 然后用备份超级块执行检查修复：

  e2fsck -b <你找到的备份超级块位置> /dev/sdb1
  

  注意：执行e2fsck前一定要确保磁盘分区没挂载，如果提示设备忙，可以先进入单用户模式再操作，避免损坏数据。

3. 手动建立加密映射并挂载 #

如果密钥已经正确加载但没自动建立映射，咱们手动操作：

• 建立LUKS映射：

  cryptsetup luksOpen /dev/sdb1 data_disk_mapper
  

  如果需要指定BEK密钥文件，就用这个命令：

  cryptsetup luksOpen /dev/sdb1 data_disk_mapper --key-file /path/to/your/bek/file
  

• 映射成功后，挂载到指定目录：

  mount /dev/mapper/data_disk_mapper /mnt/data
  

4. 检查开机自动挂载的配置（如果是开机挂载失败） #

如果是开机时挂载失败，还要检查/etc/fstab和/etc/crypttab的配置：

• 用blkid /dev/mapper/data_disk_mapper获取映射卷的UUID，然后更新/etc/fstab：

  UUID=<映射卷的UUID> /mnt/data ext4 defaults 0 0
  

• 在/etc/crypttab里添加自动解锁配置，让系统开机时自动用BEK密钥解锁磁盘：

  data_disk_mapper /dev/sdb1 /path/to/your/bek/file luks
  

5. 验证Azure侧的磁盘加密配置 #

有时候恢复时数据盘的加密参数没和原盘匹配：

• 登录Azure门户，检查恢复后的data disk的加密设置，确认它使用的BEK和KEK和原虚拟机的完全一致
• 确保恢复过程中，数据盘的加密类型（Azure Disk Encryption with BEK and KEK）和原盘一致

如果以上步骤都试过还是不行，你可以把cryptsetup luksDump /dev/sdb和dumpe2fs /dev/sdb1的输出贴出来，我再帮你定位具体问题。

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