我们在数据中心获得了这款固件版本为 3.8.1 Build 20121205 的 QNAP TS-859U+。它配备 Intel(R) Atom(TM) CPU D525 @ 1.80GHz 处理器和 1GB RAM，8 个 3TB（Seagate ST33000651AS CC44）驱动器，它们组成了一个 7 驱动器 RAID5 阵列。另一个磁盘是全局备用磁盘。
我的目的是恢复尽可能多的数据。
断电后，出现以下日志消息：
[RAID5 磁盘卷：驱动器 1 2 8 4 5 6 7] 文件系统不干净。建议您运行“检查磁盘”。
该 RAID5 逻辑卷仍处于挂载状态，我们有机会从 QNAP Web GUI 启动文件系统检查。但我们决定在下班后执行此操作，以免给用户带来任何不便。但我们再也没有机会了，因为设备自行重启，RAID5 逻辑卷变为“未挂载”，因此无法再从 GUI 启动文件系统检查，因为“立即检查”按钮变为非活动状态。
我启动了所有驱动器的“坏块扫描”，所有驱动器均成功完成。SMART 信息全部显示“良好”。
然后我尝试通过 SSH 手动挂载该卷，这是输出：
[~] # mount /dev/md0 /share/MD0_DATA -t ext4
wrong fs type, bad option, bad superblock on /dev/md0, missing codepage or other error
此次挂载尝试在 dmesg 上的反映：
[ 187.927061] EXT4-fs (md0): ext4_check_descriptors: Checksum for group 0 failed (50238!=44925)
[ 187.927297] EXT4-fs (md0): group descriptors corrupted!
以下是设备启动时的较长的 dmesg 输出：
[ 181.203693] raid5: device sda3 operational as raid disk 0
[ 181.203794] raid5: device sdg3 operational as raid disk 6
[ 181.203893] raid5: device sdf3 operational as raid disk 5
[ 181.203992] raid5: device sde3 operational as raid disk 4
[ 181.204095] raid5: device sdd3 operational as raid disk 3
[ 181.204199] raid5: device sdh3 operational as raid disk 2
[ 181.204302] raid5: device sdb3 operational as raid disk 1
[ 181.219295] raid5: allocated 119008kB for md0
[ 181.219532] 0: w=1 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.219634] 6: w=2 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.219732] 5: w=3 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.219830] 4: w=4 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.219928] 3: w=5 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.220030] 2: w=6 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.220129] 1: w=7 pa=0 pr=7 m=1 a=2 r=7 op1=0 op2=0
[ 181.220230] raid5: raid level 5 set md0 active with 7 out of 7 devices, algorithm 2
[ 181.220402] RAID5 conf printout:
[ 181.220492] --- rd:7 wd:7
[ 181.220582] disk 0, o:1, dev:sda3
[ 181.220674] disk 1, o:1, dev:sdb3
[ 181.220767] disk 2, o:1, dev:sdh3
[ 181.220859] disk 3, o:1, dev:sdd3
[ 181.220951] disk 4, o:1, dev:sde3
[ 181.221048] disk 5, o:1, dev:sdf3
[ 181.221144] disk 6, o:1, dev:sdg3
[ 181.221324] md0: detected capacity change from 0 to 17993917661184
[ 182.417718] md0: unknown partition table
[ 182.680943] md: bind<sdf2>
[ 184.776414] md: bind<sdg2>
[ 186.852363] md: bind<sdh2>
[ 187.927061] EXT4-fs (md0): ext4_check_descriptors: Checksum for group 0 failed (50238!=44925)
[ 187.927297] EXT4-fs (md0): group descriptors corrupted!
我检查了一下，发现 RAID 对于 md0 处于活动状态：
[~] # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md0 : active raid5 sda3[0] sdg3[6] sdf3[5] sde3[4] sdd3[3] sdh3[7] sdb3[1]
17572185216 blocks super 1.0 level 5, 64k chunk, algorithm 2 [7/7] [UUUUUUU]
md13 : active raid1 sda4[0] sdc4[7] sdh4[6] sdg4[5] sdf4[4] sde4[3] sdd4[2] sdb4[1]
458880 blocks [8/8] [UUUUUUUU]
bitmap: 0/57 pages [0KB], 4KB chunk
md9 : active raid1 sda1[0] sdc1[7] sdh1[6] sdg1[5] sdf1[4] sde1[3] sdd1[2] sdb1[1]
530048 blocks [8/8] [UUUUUUUU]
bitmap: 0/65 pages [0KB], 4KB chunk
unused devices: <none>
超级块也是持久的：
[~] # mdadm --detail /dev/md0
/dev/md0:
Version : 01.00.03
Creation Time : Tue Jun 14 13:16:30 2011
Raid Level : raid5
Array Size : 17572185216 (16758.14 GiB 17993.92 GB)
Used Dev Size : 2928697536 (2793.02 GiB 2998.99 GB)
Raid Devices : 7
Total Devices : 7
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Sun Apr 12 14:55:35 2015
State : clean
Active Devices : 7
Working Devices : 7
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
Name : 0
UUID : 43865f30:c89546e6:c4d0f23f:d3de8e1c
Events : 16118285
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3
7 8 115 2 active sync /dev/sdh3
3 8 51 3 active sync /dev/sdd3
4 8 67 4 active sync /dev/sde3
5 8 83 5 active sync /dev/sdf3
6 8 99 6 active sync /dev/sdg3
我尝试了各种e2fsck_64（甚至 e2fsck_64_qnap）命令组合如：
e2fsck_64 -f /dev/md0
e2fsck_64 -fy /dev/md0
e2fsck_64 -p /dev/md0
..当然是在“添加额外交换”仪式之后，因为否则它会很快抛出“内存分配错误”：
swapoff /dev/md8
mdadm -S /dev/md8
mkswap /dev/sda2
mkswap /dev/sdb2
mkswap /dev/sdc2
mkswap /dev/sdd2
mkswap /dev/sde2
mkswap /dev/sdf2
mkswap /dev/sdg2
mkswap /dev/sdh2
swapon /dev/sda2
swapon /dev/sdb2
swapon /dev/sdc2
swapon /dev/sdd2
swapon /dev/sde2
swapon /dev/sdf2
swapon /dev/sdg2
swapon /dev/sdh2
扫描如下：
/dev/md0: Inode 255856286 has compression flag set on filesystem without compression support.
如果我使用e2fsck_64 -p，它还添加了一个已清除。消息出现在行末。但它没有进一步发展。同时，e2fsck_64 进程的 CPU 使用率下降到 ~0.9%，但它仍然使用大约 %46 的内存。它似乎没有做出任何努力。系统 RAM 几乎已满，但似乎不再填充任何交换空间。
我尝试添加一个 USB 记忆棒作为更大的交换空间，正如用户 RottUlf 在此处描述的那样：http://forum.qnap.com/viewtopic.php?p=216117但它并没有改变任何事情。
我还在创建配置文件/etc/e2fsck.conf像这样：
[scratch_files]
directory = /tmp/e2fsck
dirinfo = false
..并使用 USB 记忆棒实现此目的：
mkdir /tmp/e2fsck
mount /dev/sds /tmp/e2fsck
..正如这里提到的：http://forum.qnap.com/viewtopic.php?f=142&t=102879&p=460976&hilit=e2fsck.conf#p460976
这也没有帮助。
一些文档建议尝试使用备份超级块运行 e2fsck_64 但我找不到：
[~] # /usr/local/sbin/dumpe2fs /dev/md0 | grep superblock
dumpe2fs 1.41.4 (27-Jan-2009)
/usr/local/sbin/dumpe2fs: The ext2 superblock is corrupt while trying to open /dev/md0
Couldn't find valid filesystem superblock.
最后，我尝试重新创建突袭mdadm -CfR --assume-clean因为我读到它帮助了一些遇到类似问题的人，让他们挂载卷并查看他们的数据，以便他们可以备份：
[~] # mdadm -CfR --assume-clean /dev/md0 -l 5 -n 7 /dev/sda3 /dev/sdb3 /dev/sdh3 /dev/sdd3 /dev/sde3 /dev/sdf3 /dev/sdg3
mdadm: Defaulting to version 1.-1 metadata
mdadm: /dev/sda3 appears to contain an ext2fs file system
size=392316032K mtime=Thu Jan 1 02:00:00 1970
mdadm: /dev/sda3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: /dev/sdb3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: /dev/sdh3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: /dev/sdd3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: /dev/sde3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: /dev/sdf3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: /dev/sdg3 appears to contain an ext2fs file system
size=818037952K mtime=Thu Jan 1 02:00:00 1970
mdadm: /dev/sdg3 appears to be part of a raid array:
level=raid5 devices=7 ctime=Tue Jun 14 13:16:30 2011
mdadm: array /dev/md0 started.
..但它没有帮助，仍然无法安装，同样的错误。
我们还有一个更强劲QNAP，型号 TS-EC879U-RP，固件版本 3.8.4 Build 20130816。它有大约 3.76 GB 可用 RAM 和 Intel(R) Xeon(R) CPU E31225 @ 3.10GHz 处理器。但它完全充满了另一组重要数据。
因此，我的想法是关闭两个 QNAP，取出所有 8 个磁盘并标记插槽顺序，让 QNAP 的所有 8 个磁盘保持在安全的地方，并将 TS-859U+ 的磁盘以正确的顺序放在 TS-EC879U-RP 上，然后在那个强大的 QNAP 上运行 e2fsck_64。但我不知道另一个 QNAP 是否会在“未安装”状态下正确检测到有问题的 RAID...
..或者，在强大的 QNAP 成功完成 e2fsck_64“客户磁盘”并且我将所有磁盘放入其原始插槽并打开电源后，强大的 QNAP 上的数据将被保留。
任何帮助将不胜感激，
提前致谢..
答案1
磁盘的顺序无关紧要，RAID 的配置存储在控制器上，该控制器位于旧系统中，将磁盘移动到另一个控制器只会提供 8 个新磁盘供其使用。它不会知道任何现有数据。
文件系统是否加密了，还是只是标准 RAID 5？下次使用 RAID 6 :)
答案2
在将所有 7 个驱动器连接到 PC 后，我成功地在 TestDisk 的帮助下恢复了几乎所有数据。TestDisk 成功地检测到了 RAID5 卷上损坏的文件系统并完整地导出了大部分数据。