我有一个带有 8 个磁盘的 QNAP 服务器。我有 2 个未使用的备份/额外磁盘。 （我有钱，知道最终运行的磁盘需要更换）完整的阵列分布在 8 个磁盘上，每个磁盘 @6TB...数学...但我很确定目前只有不到 1/3 被填满。
我让 QNAP 的一位代表处理了这个问题，他说双盘潜水很可能无法恢复。我相信这位代表知道他被允许/可以做什么……但是……
我见过人们从这种灾难中恢复过来的情况。我的希望在于，根据系统，所有磁盘仍然完好？？？
获取“错误的幻数”/“无法找到有效的文件系统超级块”
这是代表之前和代表之后的设备诊断输出：
**** 前 ****：
RAID metadata found!
UUID: cccd0319:89c30791:58322cfe:12ed5c64
Level: raid5
Devices: 8
Name: md1
Chunk Size: 64K
md Version: 1.0
Creation Time: Mar 23 11:49:45 2017
Status: OFFLINE
===============================================================================
Disk | Device | # | Status | Last Update Time | Events | Array State
===============================================================================
5 /dev/sdl3 0 Active Apr 28 08:03:55 2019 3927 AAAAA.AA
6 /dev/sdk3 1 Active Apr 28 08:03:55 2019 3927 AAAAA.AA
7 /dev/sdj3 2 Active Apr 28 08:03:55 2019 3927 AAAAA.AA
-------------- 3 Missing -------------------------------------------
9 /dev/sdh3 4 Active Apr 28 08:03:55 2019 3927 AAAAA.AA
10 /dev/sdg3 5 Active Apr 23 15:03:27 2019 3515 AAAAAAAA
11 /dev/sdf3 6 Active Apr 28 08:03:55 2019 3927 AAAAA.AA
12 /dev/sde3 7 Active Apr 28 08:03:55 2019 3927 AAAAA.AA
===============================================================================
**** 后 ****：
RAID metadata found!
UUID: a6860c7d:0b020f8d:1a61ec72:4684aeb7
Level: raid5
Devices: 8
Name: md1
Chunk Size: 64K
md Version: 1.0
Creation Time: Apr 29 14:08:04 2019
Status: ONLINE (md1) [UU_UUUUU]
===============================================================================
Disk | Device | # | Status | Last Update Time | Events | Array State
===============================================================================
12 /dev/sde3 0 Active Apr 29 14:38:42 2019 331 AAAAAAAA
11 /dev/sdf3 1 Active Apr 29 14:38:42 2019 331 AAAAAAAA
10 /dev/sdg3 2 Rebuild Apr 29 14:38:42 2019 331 AAAAAAAA
9 /dev/sdh3 3 Active Apr 29 14:38:42 2019 331 AAAAAAAA
8 /dev/sdi3 4 Active Apr 29 14:38:42 2019 331 AAAAAAAA
7 /dev/sdj3 5 Active Apr 29 14:38:42 2019 331 AAAAAAAA
6 /dev/sdk3 6 Active Apr 29 14:38:42 2019 331 AAAAAAAA
5 /dev/sdl3 7 Active Apr 29 14:38:42 2019 331 AAAAAAAA
===============================================================================
答案1
几乎不可能真正回答，因为没有人确切知道你之前/之后之间到底发生了什么。请对我下面的推论持保留态度——不可能肯定地说事情是这样发生的，但从你提供的数据来看，情况是这样的。
您的（之前）显示 1 个驱动器完全丢失，另一个驱动器明显过时。 （4 月 23 日与 4 月 28 日，事件计数 3515 与 3927）。
你的（之后）一团糟。事件计数重置 (331)，驱动器顺序完全不同（sde3 是 #7，现在是 #0。sdf3 是 #6，现在是 #1。等等），不清楚如何恢复丢失的驱动器和过时的驱动器强行放回阵中。此外，它显示驱动器 #2 正在重建，即使驱动器 #3 丢失且驱动器 #5 已过期。
基本上看起来像是有人重新创建了 RAID，如果操作正确的话可以工作，但是只有当你真正知道自己在做什么但你不知道的时候。除非您能解释驱动器顺序的更改，否则看起来这里做得不正确。
如果这些假设是正确的，那么在您的（之前）状态下，数据恢复的机会仍然很大。即使文件系统本身被攻击，自故障事件（4 月 23 日）以来未修改的任何文件都应该未损坏并且在某种程度上是可恢复的。
随着重新创建重新同步的驱动器和重建的进行，可能会破坏驱动器 #7 和 #2 上的数据，这种恢复的机会现在为零，或者更确切地说减少到小于 chunksize 的文件，在您的情况下恰好是64K。对于代码片段来说已经足够了，但除此之外就没有什么了。
此时可以拯救您的一件事是，如果丢失的驱动器实际上并未发生故障，只是随机踢出，并且在 4 月 23 日之前很久没有踢出。您实际上并未说明该驱动器是否已被物理更换。
如果丢失的驱动器实际上没有缺陷，并且仍然具有有效数据，并且仍在该阵列中旋转，那么即使驱动器顺序错误，重新创建也可能不会造成额外的损坏。由于 XOR 奇偶校验计算的工作方式（任何顺序），这对于 raid5 来说是一个可能的魔术。