[教學] [技術文] 如何知道Crash左的RAID能否救回?

本帖最後由 wa124 於 2015-7-8 01:49 編輯

因見到有位ching中伏了,而我自己又曾經中伏
所以,小弟係度簡單講下點樣知道組RAID能否有機會救返

新手請直接搵Support,唔好亂黎
Synology SHR不在討論範圍,因他不是標準mdadm組成的RAID
以下動作可以係等Support既時候做,純粹令自己安心
而依d資料都可以轉交Support,等佢地快d知道咩事

以下動作需要ssh login NAS
如果無法用SSH連入NAS(即因HDD問題卡住無法boot up)
QNAP用戶:
-請蚊走所有HDD開機,係冇HDD狀態下會讀DOM上的Default Setting,然後就可以用SSH Login
-如空機開機後,仍無法用Qfinder找到NAS,很大機會是硬件問題
Synology用戶:
請直接找Support

1. 首先睇下組RAID咩情況先,以下用4隻HDD組成的RAID 5做例子
  1. [~] # cat /proc/mdstat
  2. Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
  3. md1 : active raid5 sda3[0] sdc3[3] sdb3[2] sdd3[1]
  4.                  8760934848 blocks super 1.0 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
複製代碼
最底果行 [UUUU]代表4隻HDD都online,如果少左2個U或以上,就代表RAID已經Crash
但,依個情況絕對唔係代表冇得救,我就是成功例子

2. 利用mdadm -E /dev/sd[abcd]3 檢查superblock
mdadm -E 可以檢查RAID Superblock的狀態
市面上的NAS,大部分都係將個HDD分成3-5個Partition
而我地只需要睇第3個partition的superblock (Synology / QNAP data都是在第三個partition)
P.S. /dev/sd[abcd] , abcd代表唔同HDD

如果HDD RAID superblock仍然存在的話,會有以下輸出
如果冇料到,代表HDD已死
如RAID5 有多於一隻HDD搵唔到Superblock,基本上冇得救....
  1. [~] # mdadm -E /dev/sda3
  2. /dev/sda3:
  3.           Magic : a92b4efc
  4.         Version : 1.0
  5.     Feature Map : 0x0
  6.      Array UUID : fa16d562:c85e8a7c:550d5703:866b432f
  7.            Name : 1
  8.   Creation Time : Tue Jul  8 17:04:38 2014
  9.      Raid Level : raid5
  10.    Raid Devices : 4

  11. Avail Dev Size : 5840623240 (2785.03 GiB 2990.40 GB)
  12.      Array Size : 8760934848 (8355.08 GiB 8971.20 GB)
  13.   Used Dev Size : 5840623232 (2785.03 GiB 2990.40 GB)
  14.    Super Offset : 5840623504 sectors
  15.    Unused Space : before=0 sectors, after=272 sectors
  16.           State : clean
  17.     Device UUID : ba111962:2fd77e0b:fbf9caa9:d8da27fa

  18.     Update Time : Wed Jul  8 00:58:04 2015
  19.        Checksum : 8a303a50 - correct
  20.          Events : 24

  21.          Layout : left-symmetric
  22.      Chunk Size : 64K

  23.    Device Role : Active device 0
  24.    Array State : AAAA ('A' == active, '.' == missing, 'R' == replacing)
複製代碼
3. 再檢查關鍵的Parameter
- Update Time
- Events
  1. [~] # mdadm -E /dev/sd[abcd]3 |grep "Creation Time"
  2.   Creation Time : Tue Jul  8 17:04:38 2014
  3.   Creation Time : Tue Jul  8 17:04:38 2014
  4.   Creation Time : Tue Jul  8 17:04:38 2014
  5.   Creation Time : Tue Jul  8 17:04:38 2014

  6. [~] # mdadm -E /dev/sd[abcd]3 |grep "Update Time"  
  7.     Update Time : Wed Jul  8 00:59:36 2015
  8.     Update Time : Wed Jul  8 00:59:36 2015
  9.     Update Time : Wed Jul  8 00:59:36 2015
  10.     Update Time : Wed Jul  8 00:59:36 2015

  11. [~] # mdadm -E /dev/sd[abcd]3 |grep "Events"     
  12.          Events : 25
  13.          Events : 25
  14.          Events : 25
  15.          Events : 25
複製代碼
有時候RAID寫Crash只係因為Events個數值唔同,令RAID無法起動
如果4隻HDD,有2隻Events相同
基本上Support會幫你用依條command
唔識唔好打依句,搵Support幫忙最安全
> mdadm --assume-clean -CfR ...... (不完整,怕新手亂來)
去重新create組RAID,再檢查file system / LVM 是否存在
假如HDD冇問題的話,其實係好大機會(並不是100%,唔得只能做data recovery)救得返

講住咁多先,有錯請指正

高質文,support無限次……

TOP

回覆 2# tingcrab

Scrubbing部分交比你講

TOP

本帖最後由 tingcrab 於 2015-7-8 01:35 編輯
回覆  tingcrab

Scrubbing部分交比你講
wa124 發表於 2015-7-8 01:26


我的「三年前」S記RAID5連炒幾隻HDD的經歷
http://www.hkepc.com/forum/viewt ... p;extra=&page=1

原本我想講返點樣係crontab度加返果句 echo repair > /sys/block/md2/md/sync_action,但我竟然telnet返我部1511+搵唔返……

基本上,行RAID5唔似呢度好多c兄咁講得咁嚴重,但最緊要就係……
至少每個月做一次Data Scrubbing……

講堅,當大家一斷講緊行乜software RAID5出事,死左會易死另一隻等云云時,我部1511+加兩個DX510,總共15隻Hard Disk,三set RAID5默默姦雲地行左三年(更正係三年,因半年後出事才醒水)下,從未試過再有死完一隻再一隻的事例發生;而每當發現有hard disk死果時,其實並非係個RAID話返俾我聽有問題而係個s.m.a.r.t.報返我知……

所以我可以肯肯定經我幾年既field test,定期做data scrubbing係絕對地係有幫助~~(當然你係都唔信我就由你)

TOP

本帖最後由 wa124 於 2015-7-8 01:40 編輯

回覆 4# tingcrab

應該係用check
The check operation scans the drives for bad sectors and automatically repairs them. If it finds good sectors that contain bad data (the data in a sector does not agree with what the data from another disk indicates that it should be, for example the parity block + the other data blocks would cause us to think that this data block is incorrect), then no action is taken, but the event is logged (see below). This "do nothing" allows admins to inspect the data in the sector and the data that would be produced by rebuilding the sectors from redundant information and pick the correct data to keep.

用repair會有風險
Users may alternatively echo repair to /sys/block/md0/md/sync_action but this is ill-advised since if a mismatch in the data is encountered, it would be automatically updated to be consistent. The danger is that we really don't know whether it's the parity or the data block that's correct (or which data block in case of RAID1). It's luck-of-the-draw whether or not the operation gets the right data instead of the bad data.


簡單d講,data scrubbing可以有效避免HDD因bad sector做成Timeout,而被RAID踢走
(雖然依個情況係有得救)
而write hole問題,只能用UPS去預防

TOP

回覆  tingcrab

應該係用check


用repair會有風險
wa124 發表於 2015-7-8 01:32


我最慘係愛情片太多,儲多過睇,我無辦法逐一驗證佢地既file integrity……不過係有少問題既係,我某dfile檔係rename左去另一個不知明既名,例如乜乜INU013.東京bulldog10-XXX.jpg咁會變左9XA6BU.jpg……但開著佢又無事,可能係我長期用長中文檔名所致……

TOP

回覆 6# tingcrab

用repair後一定要check filesystem
File System有問題就會有好多古怪野出現.....

TOP

多謝分享。

TOP

教學post竟然冇人推

TOP

支持SUPPORT一下

TOP