HDL GT（つかの間の）復旧

今後必要になる情報とも思えないけど、一応記録を。

我が家で使ってる安全なストレージは主に3種類あって

• HDL-GT（250GBx4でRAID5）：妻のデジタル原稿、家族の写真とか過去のライブ動画、あと大量の音源など。昔はこれがストレージのメインだったけど、数年前にRAID崩壊して業者に復旧してもらってからは新しいデータはほぼ置いていない。
• サーバマシン（2TBx2でRAID1）：キューブマシンにHDD詰め込みたくないしで復旧も楽なRAID1のミラー構成。サーバ上で動いてる複数のVMのイメージもこの上に置かれてる。HDL-GT復旧時のコピーもここにあるにはある。HDL-GT側をnfs serverとしてハックしてあって、autofs使ってrsyncできるようにしてあったんだけど、syncはマニュアルでごくたまに。今思えばautofsが悪さしてた可能性も。
• Google Drive：最近は写真とか勝手にクラウドにいってくれるし、データとかもドライブにぽいぽい突っ込んでる。VMイメージ置くには辛いけど、それ以外の用途ではこいつが本命。

で、HDL-GTが再びRAID崩壊を（半年ほど前に）起こして、このまま引退してもらおうと思ったら年賀状のための住所録がそこに、という話。すみなせん、今年の年賀状は例年以上に遅かった。

崩壊としてはそれほど酷い状況じゃないはずで……というのも、HDL-GTをほとんど使ってないのと、そもそも一番上のスロット1の受け側が壊れかけててディスクに異常がなくても頻繁にRAID再構成が起きてたような状況でした。今回はOSハングから強制リブートした際に、スロット1が再構成中、さらにスロット3のタイムスタンプがズレていて同期できない、というもので、おそらく物理的には破損してないはず。この辺（検討の際に色々と参考にさせてもらったページ）にディスク構成について詳しい説明がありますが、システム周りのパーティションは4台全てでミラーした4重化RAID1で、4台中3台以上が一致してないとブートしてくれなくなっちゃうという。せっかく4重化してるなら多数決で良きに計らってくれれば嬉しかったんだけど……。OSハングは具体的にはtelnetするとloginプロンプトまではいくけど、ログイン時にToo many open filesが出てbashがあがらないという状況でした。

で、目論見としてはmadamでスロット2〜4を強制的に同期させればブート可能かつデータのRAID5も再構成可能な状況になるよね、という期待。あとはバックアップしてから作業するか、適当にトライして失敗したらデータは諦めるか、なんだけど。ちょっと住所録失うのは怖かったのでバックアップする事に。3TBのディスクを1万ちょっとで購入して、作業後はサーバの定期的なバックアップに流用する事にしました（ミラーだけだと心もとないので）。

作業に使ったマシンはWindows 7と共にほぼ忘れ去られていたHP ProLiant ML115。こんなこともあろうかと、というやつですね。なぜかこういう事する人はみんな持ってる不思議なマシン。

まずはバックアップの手順。Windows 7からダウンロードしてきたUbuntu 14.04.1のイメージを焼いてパワーオフ。違いがあるかわからないけど、イメージはサーバ版を使いました。念のため。SATA1のディスクを新しい3TBのものに差し替えてDVD起動＆インストール、パワーオフ。

続けて、SATA2/3にHDL-GTのスロット1/2を追加した状態でSATA1にインストールしたUbuntuから起動。

# dd if=/dev/sdb of=/opt/backup/HDL-GT-slot1-sdd ibs=512 obs=512 conv=noerror,sync 

# dd if=/dev/sdc of=/opt/backup/HDL-GT-slot2-sda ibs=512 obs=512 conv=noerror,sync

で、終わったらSATA2/3のディスクを抜いてをスロット3/4のディスクに差し替えて

# dd if=/dev/sdd of=/opt/backup/HDL-GT-slot3-sdb ibs=512 obs=512 conv=noerror,sync 

# dd if=/dev/sde of=/opt/backup/HDL-GT-slot4-sdc ibs=512 obs=512 conv=noerror,sync

これで、うっかりしてもやり直しはきく。ちなみに各コマンドは250GBのデータをコピーしてだいたい1時間ですね。コピー元はどちらもSATA2/3を使ってるんだけど、hotplugで差し替えたらきちんと別の名前が付いてくれました。SATA1(sda)は起動に使ってるシステムのディスク。なので1回目がsdb/sdcで2回目はsdd/sdeをifで指定。ofにはHDL-GT-に続けてスロット番号-本来のデバイス名sdd/sda/sdb/sdcを指定してます。なぜかスロット2/3/4/1の順に名前が付いてたみたい。さらに、前回の崩壊からの復旧時にスロット1/2は500GBのカートリッジになってた模倣。そう言えば、在庫なかったんで500GB使いました、とか言われた気がする。当時はラッキーとか思ってたけど、今回2時間余計に時間かかっただけでメリットは何もなかった（コピー後にサイズ見て思い出した）。

で、次はRAIDの救済。ちなみにHDL-GTで検索して「RAIDの復旧」として説明しているページがいくつかあるんですが、復旧と言ってもHDL-GTを初期状態に戻してまたRAIDサーバとして使えるようにする作業の説明であって、データのサルベージではなかったりするようなので要注意です。とりあえずはHDD全部外してUbuntuのDVDから起動してお試しモードでスタート。mdadmが入ってないので

# apt-get install mdadm

でインストール。今度はSATA1-4にスロット1-4を挿します。mdadm --examineでディスク名が一致するよう、2/3/4/1の順で挿します。で、念のためにmdstatを確認……して驚く。

$ cat /proc/mdstat
Personalities : [raid1]
md5 : inactive sdd5[1](S) sdc5[3](S) sdb5[2](S)
      1590144 blocks
md10 : inactive sdd6[4](S) sdc6[3](S) sdb6[2](S)
      725768256 blocks
md1 : inactive sdd1[1](S) sdc1[3](S) sdb1[2](S)
      626304 blocks
md2 : active sdd2[1] sdc2[3] sdb2[2]
      409536 blocks

おぉ、さっそく出来上がっちゃってる！追加する順番を気にしたかったので、一度全部解除。

# mdadm --misc --stop /dev/md1
# mdadm --misc --stop /dev/md2
# mdadm --misc --stop /dev/md5
# mdadm --misc --stop /dev/md10

で、ここから比較的安定してたはずの3本を使ってRAIDを構成。

# mdadm -A --run --force /dev/md1 /dev/sda1 /dev/sdb1 /dev/sdc1
$ cat /proc/mdstat
Personalities : [raid1]
md1 : active sda1[0] sdc1[3] sdb1[2]
      208768 blocks [6/3] [U_UU__]
unused devices:

うまくいってるようなので、残りの一本も追加。

# mdadm --add /dev/md1 /dev/sdd1
$ cat /proc/mdstat
Personalities : [raid1]
md1 : active sdd1[1] sda1[0] sdc1[3] sdb1[2]
      208768 blocks [6/4] [UUUU__]
unused devices:

他のデバイスも同様に復旧。

# mdadm -A --run --force /dev/md2 /dev/sda2 /dev/sdb2 /dev/sdc2
$ cat /proc/mdstat
Personalities : [raid1]
md2 : active sda2[0] sdc2[3] sdb2[2]
      409536 blocks [6/3] [U_UU__]
md1 : active sdd1[1] sda1[0] sdc1[3] sdb1[2]
      208768 blocks [6/4] [UUUU__]
unused devices:
# mdadm --add /dev/md2 /dev/sdd2
$ cat /proc/mdstat
Personalities : [raid1]
md2 : active sdd2[6] sda2[0] sdc2[3] sdb2[2]
      409536 blocks [6/3] [U_UU__]
      [========>............] recovery = 41.5% (169984/409536) finish=0.0min speed=84992K/sec

今度は最後の一本で同期が始まったけど、この程度なら一瞬で終了。md5、md10も同様にsda5,6/sdb5,6/sdc5,6から構成して別途sdd5,6を追加、しばらく同期待ちをする事で問題なくactiveになりました。で、次が緊張の一瞬。

# mdadm -A --run /dev/md13 /dev/md10

こいつもエラーなくあっさりactiveにできました。で、ここからが問題。参考にしたサイトではこいつをxfsでマウント

# mount -t xfs /dev/md13 /somewhere

してあげれば、少なくともshareが存在することがわかる、と。あるんですが、我が家の場合はマウントするも中身は空。XFSはジャーナリングがアーキテクチャ依存なので、xfs_repair使って云々、みたいなことがあちこちで書かれてるんですが、そもそもxfs_repairかけるとxfs_repairがcrash。なんか、他の人とは根本的に違うようです。

で、結論から言うと、この段階でHDL-GTにディスクを戻せば完璧に復活しました。なのでxfsが読めなかった件は忘れるつもりでいたのですが……ここで問題発生。住所録を読み出してバックアップのrsyncをかけたら……また死亡。今度は電源が飛んで本気の死亡状態のようです。風前の灯火だったのか。

という事で、どうやらxfs問題と向き合うしかないようです。で、以下は調査と推測の入り混じった結論になるのですが、

• XFSは基本的にはプラットフォーム非依存なのだが、昔懐かしのARM OABIの環境において意図しない互換性の問題が存在していた。32-bitのmiddle endianだったり、structがpackされてたり、と癖のあるABIだったのが敗因か。
• ARM OABIからEABIの移行でXFSが飛ぶ問題があちこちで報告されている。
• HDL-GTを買ったのは2006年。まだOABIが主流だった時期。玄箱はOABI、玄箱ProはEABI。
• 推測：微妙に読めたり、xfs_repairで復旧できてる人たちはEABIに移行後の後期のHDL-GTシリーズを使っていたのではないか。
• 推測：OABI環境ならmountできるに違いない。

そんなわけで、玄箱に繋げて読もうとしたんですが、そもそもSATAポート空いてない＆玄蔵使ってUSB経由で接続すると認識されない。間に入ってるSCSI仮想レイヤあたりで3TBがうまく扱えてないのか。という事で、次は何を試そうかな、というのが昨晩くらいの状況。運のいい人にとってはここまでの情報でも役に立つかもしれないので、ひとまずpublish。