2015年9月24日木曜日

NASの自作 Part41

今日はRAIDの復旧をテストしてみます。いざHDDが壊れた時にオペミスでデータを失っては身も蓋もないないので、テストは重要です。昨日、ComicCafeの移行テストで使用した自炊ファイルを使って検証します。HDDを壊す前に今あるファイルのMD5ハッシュを計算しておきます。
# 自炊ファイルが保存してあるディレクトリに移動
cd /media/74a33bfa-edae-4b56-92cc-33fa5c44ba82/shared
# 私の自炊ファイルは全てzipファイルです。
find . -type f -name "*.zip" -exec md5sum {} \; | sort -k 1
次にデュアルブートのWindows10を起動して、任意の2台のHDDをフォーマットします。


001

002

003

今回はなんとなく2と5のディスクを初期化してみました。初期化後にOMVを起動してRAIDの状態を確認してみます。
# 10台中8台でRAIDが構成されている
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sdd[1] sdf[9] sdk[7] sdg[6] sdl[5] sdi[4] sdj[3] sdm[2]
      23441080320 blocks super 1.2 level 6, 512k chunk, algorithm 2 [10/8] [_UUUUUUU_U]
      
unused devices: none

# 2台のHDDがremovedになっている
mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Wed Aug 19 23:22:08 2015
     Raid Level : raid6
     Array Size : 23441080320 (22355.16 GiB 24003.67 GB)
  Used Dev Size : 2930135040 (2794.39 GiB 3000.46 GB)
   Raid Devices : 10
  Total Devices : 8
    Persistence : Superblock is persistent

    Update Time : Thu Sep 24 09:13:50 2015
          State : clean, degraded
 Active Devices : 8
Working Devices : 8
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : OMV-NODE804:10DisksRAID6  (local to host OMV-NODE804)
           UUID : 22a559e2:1d468c1e:75c0ffeb:2b2e8494
         Events : 145

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       48        1      active sync   /dev/sdd
       2       8      192        2      active sync   /dev/sdm
       3       8      144        3      active sync   /dev/sdj
       4       8      128        4      active sync   /dev/sdi
       5       8      176        5      active sync   /dev/sdl
       6       8       96        6      active sync   /dev/sdg
       7       8      160        7      active sync   /dev/sdk
       8       0        0        8      removed
       9       8       80        9      active sync   /dev/sdf
2台のHDDに障害が発生している状態でもRAID6なので、データは失われていないはずです。先ほどと同じコマンドでハッシュ値を計算して比較し、ファイルの無事を確認できました。次にHDDを復旧させてみます。実運用では新しいHDDを買って差し替えることになりますが、今回はHDDはそのままで復旧作業をしてみます。
# kernel が認識しているパーティションテーブル一覧を取得
cat /proc/partitions
major minor  #blocks  name

   8       16  250059096 sdb
   8       17  250056704 sdb1
   8        0  117220824 sda
   8        1  112429056 sda1
   8        2          1 sda2
   8        5    4789248 sda5
   8       32 2930266584 sdc
   8       33     131072 sdc1
   8       48 2930266584 sdd
   8       64   30528032 sde
   8       65   30527008 sde1
   8       80 2930266584 sdf
   8       96 2930266584 sdg
   8      128 2930266584 sdi
   8      112 2930266584 sdh
   8      113     131072 sdh1
   8      144 2930266584 sdj
   8      160 2930266584 sdk
   8      176 2930266584 sdl
   8      192 2930266584 sdm
   9        0 23441080320 md0
# 先ほどのRAIDの状態確認で表示されなかったsdcとsdhが破損していることが分かる
本来なら障害時には以下の様なコマンドでデバイスの状態をFailにして、RAIDからデバイスを取り除く作業が必要のようですが、今回はWindowsからフォーマットしたせいか既にremovedの状態になっているので、このまま復旧作業をすることにします。
# 故障したデバイスをFailにする
mdadm /dev/md0 -f /dev/sdc1
mdadm /dev/md0 -f /dev/sdh1
# 故障したデバイスをRAIDから取り除く
mdadm /dev/md0 -r /dev/sdc1
mdadm /dev/md0 -r /dev/sdh1
復旧はWebの管理画面から[RAID Management]->[Recover]で簡単に実行できるようです。

AccessMenuBarApps 0
交換したデバイスを指定します。

AccessMenuBarApps 2
設定を保存するとRAIDのリビルドが自動的に実行されます。これは初回のRAID構築時と同じで8時間ぐらいかかりそうです。
AccessMenuBarApps 3

リビルドが必要になるので復旧作業にはかなり時間がかかりそうですが、Webの管理画面から簡単に復旧できるのは素晴らしいの一言です。

0 件のコメント:

コメントを投稿