Storage

QNAP TS-859U+ RAID5 卷已解除安裝,e2fsck_64 掛起

  • August 14, 2017

我們在我們的數據中心獲得了這款韌體版本為 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 Disk Volume: Drive 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!

我檢查了 md0 的 RAID 是活動的:

[~] # 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>

Superblock 也是持久的:

[~] # 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 的記憶體。我看起來不像在做任何努力。系統 RAM 幾乎已滿,但似乎不再填充任何交換空間。

正如使用者 RottUlf 在這裡描述的那樣,我嘗試添加一個 USB 記憶棒作為更大的交換: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重新創建 raid,因為我讀到它幫助了一些遇到類似問題的人,安裝他們的捲並查看他們的數據,以便他們可以備份:

[~] # 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’ing“訪客磁碟”並且我將所有磁碟放入其原始插槽並打開電源後保留。

任何幫助將不勝感激,

提前致謝..

在將所有 7 個驅動器連接到 PC 後,我在 TestDisk 的幫助下設法恢復了幾乎所有數據。TestDisk 已成功檢測到 RAID5 卷上損壞的文件系統,並完好無損地導出了大部分數據。

磁碟的順序無關緊要,RAID 的配置儲存在控制器上,該控制器位於舊系統中,將磁碟移動到另一個控制器只會提供 8 個新磁碟供其使用。它不會知道任何現有數據。

文件系統是加密的還是只是標準的 RAID 5?下次使用 RAID 6 :)

引用自:https://serverfault.com/questions/682586