Synology NAS遭遇掉电/浪涌后，含读错误且丢失RAID superblock的RAID10阵列mdadm恢复方案咨询

兄弟，先握个手——这种掉电搞崩RAID的糟心事我也碰过，太闹心了。先理清楚你目前的处境：8块6TB盘搭的RAID10，掉电浪涌后1-3盘状态正常，5-8盘有少量集中位置的不可纠正LBA读错误，还丢了RAID superblock，但fdisk能识别所有分区；你已经拿到了无superblock成员的UUID，没足够空间做全盘克隆，核心目标是抢救没备份的关键数据。

先给你梳理核心思路：RAID10是“两两镜像再条带”的结构，我们可以尝试用mdadm手动重建阵列，跳过坏块区域，尽量保留绝大多数数据。

第一步：先做关键准备，绝对别瞎操作 #

• 先把所有磁盘的RAID分区（Synology一般用分区而非整盘，比如sda1/sdb1这类）再扫一遍：mdadm --examine /dev/sdX1，把阵列的UUID、chunk大小、磁盘顺序这些信息记死——尤其是chunk size，Synology RAID10常用64K或128K，这个错了阵列直接废。
• 用smartctl -a /dev/sdX再检查5-8盘的健康状态，确认只有那几个集中的LBA读错误，没有大面积坏道，不然强行重建可能搞坏更多数据。
• 划重点：绝对不要在原阵列上做任何写操作！先把5-8盘的错误LBA位置用dmesg | grep -i error或者mdadm --examine的输出记下来，后面要跳过这些块。

第二步：手动重建RAID10阵列 #

因为你已经有成员UUID，且1-3盘保留了superblock，我们用mdadm --create手动重建，参数必须完全匹配原阵列：

1. 先停掉可能残留的md设备：mdadm --stop /dev/mdX（X是原阵列号，比如md2，用cat /proc/mdstat能看到）
2. 执行创建命令，替换成你的实际设备和参数：

   mdadm --create /dev/md2 --level=10 --raid-devices=8 --chunk=64K --assume-clean --uuid=你的原阵列UUID /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1
   

   几个关键参数解释：
   • --assume-clean：这是核心！告诉mdadm“我确认这些盘的大部分数据一致，先搭起阵列框架，不要立刻同步”——同步的话会直接卡在读错误的位置，甚至破坏数据。
   • 磁盘顺序必须和原阵列完全一致！RAID10的镜像对是固定的，搞反顺序数据直接乱。你可以从1-3盘的mdadm --examine输出里找RaidDevice字段，确认每块盘在阵列里的原始位置。
3. 阵列创建后，设为读写模式并尝试挂载：

   mdadm --readwrite /dev/md2
   mount /dev/md2 /mnt/recover
   

   如果挂载时提示文件系统错误，先做只读检查：fsck.ext4 -n /dev/md2（Synology默认用ext4），错误大概率集中在你之前记录的LBA区域。

第三步：处理读错误区域的文件 #

如果挂载后某些文件打不开，或者fsck报错，直接定位对应LBA的文件：

• 先通过dumpe2fs /dev/md2看文件系统块大小（一般4K），把读错误的LBA（扇区数，512字节/扇区）转换成文件系统块号：块号 = LBA号 / (块大小/512)，比如4K块的话就是LBA号 / 8。
• 用debugfs -R "testb <块号>" /dev/md2定位到对应的文件，要是非关键文件直接放弃；如果是核心数据，用dd跳过坏块提取：

  dd if=/dev/md2 of=/tmp/recover_file bs=4K skip=<正常起始块号> count=<需要提取的正常块数>
  

第四步：救回数据后的加固操作 #

• 导出关键数据后，立刻换掉那几块有读错误的盘——掉电导致的LBA错误大概率是盘的固件或磁头隐患，留着早晚出问题。
• 重新建阵列时一定要开启Synology的“写入缓存保护”，再配个UPS，这次真的别再裸奔了（懂你不想听大道理，但这是踩过坑的真心话）

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