已清零超级块的LUKS加密mdadm RAID5阵列是否可恢复？

兄弟，我太懂你这种搞混设备名的崩溃了——误清RAID超级块真的是能让人原地拍大腿的操作，先别慌，咱们一步步梳理清楚你的情况和可行的恢复方向：

先复盘你的操作 #

你先是误执行了这三个命令，清掉了3块8TB硬盘的RAID超级块：

$ sudo mdadm --zero-superblock /dev/sde
$ sudo mdadm --zero-superblock /dev/sdf
$ sudo mdadm --zero-superblock /dev/sdi

之后你尝试用--create --assume-clean重建阵列，从/proc/mdstat看阵列确实激活了，但因为是LUKS加密的，你大概率是没法正常解密挂载的对吧？

核心问题所在 #

--assume-clean这个参数是双刃剑：它告诉mdadm「这个阵列的数据已经完全同步，不用做初始化同步」，但如果你的磁盘顺序、chunk大小、RAID元数据版本和原来的阵列不一致，重建出来的阵列结构就是错的，LUKS自然识别不出原来的加密容器。

接下来的恢复步骤（关键：别往这三块盘写任何数据！） #

1. 先停掉当前的错误阵列
   避免后续误操作覆盖数据，先执行：

   sudo mdadm --stop /dev/md1
   

2. 尝试扫描残留的RAID元数据
   虽然你清了超级块，但有时候磁盘上可能还残留一些元数据痕迹，试试扫描：

   sudo mdadm --examine --scan /dev/sde /dev/sdf /dev/sdi
   

   如果能扫出原来的阵列信息，直接用mdadm --assemble组装就行，这是最理想的情况。

3. 通过LUKS签名反推RAID参数
   因为你的RAID阵列是整体被LUKS加密的，原来的RAID容器头部应该有LUKS的签名（十六进制下是4C 55 4B 53，也就是ASCII的LUKS）。你可以用dd读取每个磁盘的开头片段找这个签名：

   dd if=/dev/sde bs=512 count=100 | hexdump -C
   

   找到签名后，你需要尝试不同的RAID参数组合重建阵列，每次重建后用LUKS尝试解密：

   • 磁盘顺序：RAID5的磁盘顺序直接影响parity计算，试试所有可能的排列（比如sde sdi sdf、sdf sde sdi等）
   • Chunk大小：常见的RAID5 chunk大小是64K、128K、256K、512K，你现在用的是512K，试试其他值
   • 每次重建的命令格式（替换参数）：

     sudo mdadm --create --assume-clean --level=5 --raid-devices=3 --chunk=128K /dev/md1 /dev/[磁盘顺序]
     

   • 重建后尝试解密：

     sudo cryptsetup luksOpen /dev/md1 my_luks_container
     

     如果能成功输入密码解锁，那说明参数对了！

4. 极端情况：专业数据恢复
   如果上述尝试都失败，可能需要借助专业的数据恢复工具（比如testdisk的RAID恢复功能），或者找专业的数据恢复服务商——不过3块8TB的盘，服务商的费用会很高，这是最后的备选方案。

事后教训 #

• 以后一定要备份RAID的元数据：执行mdadm --detail --scan > /etc/mdadm/mdadm.conf，并且把这个文件备份到其他存储设备上
• 别再靠/dev/sdX这种易变的设备名识别磁盘了，用/dev/disk/by-id或者/dev/disk/by-uuid，彻底避免搞混设备

备注：内容来源于stack exchange，提问作者ray_voelker