QNAP NASのRAID5を強引に復旧した話

• RAIDリカバリ前に重要なファイルはバックアップしよう

• QNAP IntelCPU搭載のNASは基本的にはPC。QTSも基本的にはLinux

• 通常時はQTSのGUIの管理でOK。トラブル発生時はSSHが有用

TS-464: NASとして利用できるLinuxPC

データ保存用のNASとしてQNAPのTS-464を使っています。 この製品はQNAPがミドルレンジに位置付けているようで、2.5Gbpsイーサネット２ポート、M.2 2280 ２スロット、PCIe x4 (LP) １スロットと NASというよりはPCだよね。というようなマシンです。

……というか、NAS用のOSがプリンストールされたIntelPCですね。 キーボードとディスプレイを接続した状態で起動すると、見慣れたBIOS設定画面に入れたり、 USBからLinux起動したりできますし。

ディスク故障発生

HDDは消耗品ですので、使っているうちに故障したりすることもあります。

異常が出たディスクを取り外して新しいディスクを装着、あとはRAIDのリビルド完了を待つだけですね。……のはずだったんですが、数時間後NASからビープ音が鳴り響きHDDスロット１にエラー表示が。

slot 1,2,4 -> slot 3 のリビルド中で slot 1 異常セクタ発生……これはマズいですね、整合性を保てなくなったため無事RAIDがOFFLINEに。

ダメ元で slot1のHDDに不良ブロックのスキャンを試みるも復旧せず。

こんな時は落ち着いて ssh接続してみよう

NASっぽく振舞っているものの、結局はカスタマイズされたlinuxマシンです。 なので困ったらとりあえずSSH接続してみます。

QNAPはハードウェアRAIDではなく、ソフトウェアRAID (mdadm) を使っているようですので、 mdadm --examineで状態を調べてみます

$ sudo mdadm -E /dev/sdc3
/dev/sdc3:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x8
     Array UUID : de11a6ca:424f604c:e6975689:2a6fa5d8
           Name : 2
  Creation Time : Thu Dec 22 17:12:38 2022
     Raid Level : raid5
   Raid Devices : 4

 Avail Dev Size : 11701135240 (5579.54 GiB 5990.98 GB)
     Array Size : 17551701504 (16738.61 GiB 17972.94 GB)
  Used Dev Size : 11701134336 (5579.54 GiB 5990.98 GB)
   Super Offset : 11701135504 sectors
   Unused Space : before=0 sectors, after=1160 sectors
          State : clean
    Device UUID : 3306a7b5:629cb539:467c1f65:a63e4dd5

    Update Time : Sun Mar 31 03:35:12 2024
  Bad Block Log : 512 entries available at offset -8 sectors - bad blocks present.
       Checksum : 4205c7db - correct
         Events : 52851

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 0
   Array State : AA.A ('A' == active, '.' == missing, 'R' == replacing)

スロット３のHDDを外した状態で確認したため、 １台missingになっています。 残りのディスクは active、４台構成のRAID5なので３台あればとりあえず動くはずです。

試しにONLINEにしてみます。

$ sudo mdadm -AfRv -u de11a6ca:424f604c:e6975689:2a6fa5d8 /dev/md2

（略）
mdadm: /dev/sdd3 is identified as a member of /dev/md2, slot 1.
mdadm: /dev/sdc3 is identified as a member of /dev/md2, slot 65281.
mdadm: /dev/sdb3 is identified as a member of /dev/md2, slot 3.

あー。。/dev/sdc3はslot0 になるはずがとんでもないスロット番号に……
これはRAIDメタデータ壊れてますね。

とりあえず、ディスクを複製

まず、異常セクタが発生してしまったスロット１のHDD（/dev/sdc3）を新しいHDDにクローンします。

PCレスでHDDクローンを行うようなデバイスもあるのですが、エラースキップがとにかく遅い。 ddでディスクごとコピーする場合も同様ですね。
（読み書きの単位をセクタサイズに合わせないとエラースキップ時に正常なセクタも巻き込まれてスキップになってしまう）

で、そういった用途向けに GNU ddrescue というソフトがあるので、 これを使ってみます。

QTSには入っていないので別途用意する必要がありますが、ここで公式のリカバリガイドを見てみますと、 ClonezillaなるLinuxディストリビューションをUSBブートしなさい、とのこと。
（手順見ても、Intel系のPCそのものですね。）

Clonezillaにはddrescueが入っていましたので、別途PCを用意する必要もなくNASだけで完結できそうです。

メタデータだけ無理やり復旧させる

クローン取ったら、新しいほうのHDDを装着した状態でQTSを起動、sshで接続します。

sudo mdadm --create /dev/md2 --verbose --chunk=512 --level=5 --raid-devices=4 --size=5850567168 /dev/sdb3 /dev/sdc3 missing /dev/sda3

と元のRAIDと同じパラメータで mdadm --create を実行します。

パラメータは mdadm --examine の出力を元に入力します

     Array Size : 17551701504 (16738.61 GiB 17972.94 GB)
         Layout : left-symmetric
     Chunk Size : 512K

このArray SizeはRAID全体でのサイズです。４台のRAID5なので データ3:パリティ1 の比率ですから、ディスク１台あたりのサイズは 1/3 の 5850567168 になります。（単位はKB）

なお、mdadm --createはメタデータのみ書き込むようで、それ以外の領域はそのまま利用するようです。

QNAP謹製の md_checker で確認してみますと

Status:         ONLINE (md2) [UU_U]
===============================================================================================
 Enclosure | Port | Block Dev Name | # | Status |   Last Update Time   | Events | Array State
===============================================================================================
 NAS_HOST       3        /dev/sdb3   0   Active   Apr  6 03:01:10 2024        0   AA.A
 NAS_HOST       4        /dev/sdc3   1   Active   Apr  6 03:01:10 2024        0   AA.A
 ----------------------------------  2  Missing   -------------------------------------------
 NAS_HOST       6        /dev/sda3   3   Active   Apr  6 03:01:10 2024        0   AA.A
===============================================================================================

OK、ONLINEになりました。

あれ、GUIからは管理外になってる…………

RAIDはONLINEになったのですが、QTS GUIからはストレージプールが見えない状況に。

どうやらUUIDで管理しているらしく、UUIDが変わるとダメなようです。

いったんmdadm管理から外して、UUID指定のassembleで再構築してあげます。

sudo mdadm -E /dev/md2

sudo mdadm --assemble /dev/md2 /dev/sdb3 /dev/sdc3 missing /dev/sda3 --update=uuid --uuid=de11a6ca:424f604c:e6975689:2a6fa5d8

NASを再起動したら、無事にストレージプールとして認識されるようになりました。

この後は通常の RAIDリビルドの手順ですね。

まとめ

• RAIDの冗長性は、故障時にバックアップの時間的猶予ができる程度の気持ちで

• 異常が発生していなくても、たまにバックアップしておくと良い

• QNAPのNASはソフトウェアRAID。

  • ４台程度なら、ATOM系列のCPUでも特にパフォーマンスに問題は出ない模様

  • 最近のCPUは計算能力高いよね