我们在我们的数据中心得到了带有固件版本3.8.1 Build 20121205的QNAP TS-859U +。 它具有Intel（R）Atom（TM）CPU D525 @ 1.80GHz处理器和1GB RAM，8个3TB（Seagate ST33000651AS CC44）驱动器，它们构成一个7个驱动器的RAID5arrays。 另一个磁盘是全球备件。
我的意图是尽可能多的收集数据。
发生电源故障后，有这个日志消息：
[RAID5磁盘卷：驱动器1 2 8 4 5 6 7]文件系统不干净。 build议您运行“检查磁盘”。
该RAID5逻辑卷仍然挂载，我们有机会从QNAP Web GUI启动文件系统检查。 但是我们决定在工作时间之后这样做，不会给用户带来不便。 但是我们再也没有机会了，因为设备重新启动，RAID5逻辑卷变成了“Unmounted”，所以不再需要从GUI开始文件系统检查，因为“CHECK NOW”button变为不活动状态。
我开始为所有驱动器“坏块扫描”，他们都成功完成。 他们都说SMART信息“GOOD”。
然后我尝试通过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 ，它也会添加一个CLEARED。 消息在行尾。 但它不会再进一步。 同时，e2fsck_64进程'CPU使用率下降到〜0.9％，但仍然使用％46内存。 我看起来不是在做任何努力。 系统内存几乎已经满了，但是似乎没有更多的交换空间。
我试图添加一个USB棒作为一个更大的交换作为用户RottUlf在这里描述： http : //forum.qnap.com/viewtopic.php?p= 216117但它并没有改变一件事。
我还在/etc/e2fsck.conf中创build了这样的configuration文件：
[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
这也没有帮助。
一些文件build议尝试与备份超级块运行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来重新创buildraid，因为我读过它帮助那些遇到类似问题的人，获得卷的挂载并查看他们的数据以便备份：
[~] # 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的可用内存和Intel（R）Xeon CPU E31225 @ 3.10GHz处理器。 但是另外一组重要数据已经满了。
所以，我想记住的是closures两个QNAP，并把所有8个磁盘都标记为插槽顺序，将QNAP的所有8个磁盘保持在安全的地方，然后把TS-859U +的磁盘放在TS-EC879U-RP上正确的顺序，并在强大的QNAP上运行e2fsck_64。 但是我不知道其他QNAP是否能在“未安装”状态下正确检测到有问题的RAID …
..或强大的QNAP的数据将被保留后，它完成e2fsck_64“的客人磁盘”，我把所有的磁盘在原来的插槽和电源。
任何帮助将不胜感激，
提前致谢..
磁盘的顺序无关紧要，RAID的configuration存储在旧系统中的控制器上，将磁盘移动到另一个控制器时，将只显示8个新磁盘供其使用。 它不会知道任何现有的数据。
是文件系统encryption还是只是一个标准的RAID 5？ 下次使用RAID 6）
在将所有7个驱动器连接到PC之后，我已经在TestDisk的帮助下成功恢复了几乎所有的数据。 TestDisk已经设法检测RAID5卷上的损坏的文件系统，并完整地导出大部分数据。