先还原下你的整个场景和排查过程：

• 你有一台搭载Broadcom 9361-8i RAID卡的服务器，配置了两组阵列：一对14TB SAS SSD做RAID1，四块SAS机械盘做RAID10，这套配置稳定运行了三年，系统是RHEL 8.4（从独立的M.2盘启动，RAID阵列并非启动盘）。
• 为了查看硬盘的SMART信息，你安装了MegaRAID Storage Manager（MSM），并且用StorCLI成功验证了所有6块硬盘的SMART状态，当时一切正常。
• 但重启服务器后，SSD组成的RAID分区无法挂载，而机械盘的RAID分区挂载正常。

你尝试了这些排查步骤：

1. 执行fdisk -l查看分区情况，结果显示/dev/sda1是一个无意义的2TB DOS分区（类型标记为unknown），而且没有对齐物理扇区，完全看不到正常的分区表和Linux文件系统：

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 262144 bytes / 262144 bytes
Disklabel type: dos
Disk identifier: 0x64656c69

Device     Boot Start        End    Sectors Size Id Type
/dev/sda1           1 4294967295 4294967295   2T 74 unknown

Partition 1 does not start on physical sector boundary

2. 进入MegaRAID BIOS工具检查硬件状态，显示RAID1阵列一切正常，能正确识别两块14TB的SSD。
3. 尝试用fsck修复，但因为工具识别不到可检测的文件系统，没有任何效果。
4. 用gparted查看，只显示一个14TB的未分配空间；尝试内置的数据恢复功能，预估需要两周时间，因此你放弃了，而且发现恢复扫描是从2TB开始往14TB推进的。
5. 卸载并删除MSM后重启服务器，问题依旧，说明MSM大概率不是导致故障的原因。另外你提到重启前有过一次无浪涌的断电，但RAID BIOS工具并没有显示SSD存在异常。

最后你用testdisk找到了关键线索：

Disk /dev/sda - 15 TB / 13 TiB - CHS 1867708 255 63
     Partition               Start        End    Size in sectors
 P EFI System                  2048    1230847    1228800 [EFI System Partition] [NO NAME]
 P Linux filesys. data      1230848    3327999    2097152
>P Linux filesys. data      3328000 30004738047 30001410048

其中最后一个14TB的Linux数据分区就是你丢失的目标分区，选择Write partition写入分区表后，问题成功得到解决。

结论 #

从整个排查和解决过程来看，MegaRAID Storage Manager应该不是导致分区损坏的原因——卸载后问题并未解决，而且你使用StorCLI检查SMART时一切正常。更有可能是之前的断电事件导致了分区表出现异常，而RAID卡的BIOS工具仅监控阵列的硬件状态，不会检测分区表层面的问题。testdisk通过恢复正确的分区表，让系统重新识别到了RAID1阵列上的文件系统，从而解决了挂载问题。

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