兄弟，先别慌，咱们先把你的情况拆解清楚，再一步步说怎么安全处理：

首先，你的处境到底有多糟？ #

RAID 0的核心特性是无冗余条带化存储——所有数据被拆分到各个硬盘上，任何一块盘的异常（哪怕只是临时断开再插回）都可能打乱整个阵列的数据块顺序，甚至损坏分区表或RAID元数据。

标题被改成「Destroyed RAID 0 array」确实有点绝对，但你的阵列现在处于inactive状态，还出现了GPT分区表异常（/dev/sdf的备份GPT不在磁盘末尾），说明拔插硬盘的操作已经破坏了阵列的完整性，数据面临很高的丢失风险，但也不是完全没救，得看具体损坏的是RAID元数据、分区表还是实际数据块。

安全处理的第一步：绝对不要写入任何原始磁盘！ #

这是最关键的一点——不管你接下来做什么，不要对组成RAID的5块硬盘做任何写入操作（包括不要尝试重新组装阵列、修复分区表、格式化等）。任何写入都可能彻底覆盖可恢复的数据，把“有机会救”变成“彻底没救”。

接下来的安全操作步骤（按优先级来） #

1. 给所有RAID磁盘做镜像备份

找5块和原盘同容量（或更大）的硬盘，用ddrescue（比dd更安全，能跳过坏块、记录进度）把每块原始盘完整克隆到新盘上，后续所有操作都在镜像盘上进行：

# 示例：克隆/dev/sda到外接硬盘的sda.img文件，同时生成日志记录进度
ddrescue /dev/sda /mnt/external_drive/sda.img /mnt/external_drive/sda_rescue.log

重复这个命令，把5块原始盘都克隆一遍。

2. 修复GPT分区表异常（仅在镜像盘上操作）

针对fdisk提示的/dev/sdf备份GPT不在末尾的问题，用gdisk尝试修复：

gdisk /dev/sdf_clone  # 注意这里用的是镜像盘，不是原始盘

进入gdisk后，它会自动检测到备份GPT的问题，按提示：

• 输入r进入恢复菜单
• 输入b先把当前分区表备份到一个文件（留作后手）
• 输入c修复备份GPT到磁盘末尾
• 输入w保存更改（仅在镜像盘上执行！）

3. 尝试重新组装RAID阵列（仅在镜像盘上操作）

用mdadm尝试扫描并组装阵列，加上--verbose参数看详细输出：

mdadm --assemble --scan --verbose

如果扫描不到，手动指定所有镜像盘尝试组装：

mdadm --assemble /dev/md127 /dev/sda_clone /dev/sdb_clone /dev/sdc_clone /dev/sdd_clone /dev/sdf_clone

如果组装成功，一定要用只读模式挂载，避免写入损坏数据：

mount -o ro /dev/md127 /mnt/raid_recovery

挂载后尽快把重要数据复制到安全的存储设备上。

4. 如果组装失败，尝试文件级恢复

如果阵列无法组装，说明RAID元数据或数据块错位严重，这时候可以用testdisk或photorec这类工具：

• testdisk支持RAID恢复，你可以选择“RAID”模式，手动指定RAID的条带大小、磁盘顺序等参数，尝试识别分区
• photorec可以忽略分区表，直接扫描磁盘的扇区恢复文件，适合RAID彻底失效的情况，但文件名和目录结构可能丢失

最后说回你的编辑提问：RAID是不是肯定毁了？ #

不一定——如果只是RAID元数据损坏或者GPT分区表异常，修复后大概率能找回数据；但如果拔盘时系统正在进行大量读写，导致数据块错位，那大文件（比如视频、数据库文件）可能已经损坏，小文件还有机会恢复。

另外，给你提个醒：RAID 0只适合追求性能、数据有额外备份的场景，绝对不能用来存重要数据。这次就算救回来，以后也别再用RAID 0存不想丢的东西，至少用RAID 1（镜像）、RAID 5/6（带冗余），再加上定期离线备份才是正道。

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