by 会社でバッファロー製の安物NAS : TeraStation (TS-XLシリーズ：1.5TB x 4本モデル）を使っていました。RAID5構成（実質1.5×3 = 4.5TB : スペアなし）で使っていましたが、この度４本の内2本のHDDが故障するというトラブルが発生しました。その過程と復旧までの流れを紹介。
その前に・・・・。
TeraStationなんぞ使ってはいけません。今使っている人は使用をやめるべきだと個人的には思います。
・TeraStationで検索すれば、公式サイトの他に、データ復旧＋データサルベージ業者がSEOを競って掲載しています。異常な数です。これは一般的なHDDの故障率から考えても普通ではないことが予想されます。使うべきではないと思います。
・TeraStationの公式ページのファームウェアの更新履歴をみてみてください。過去から読み進んでいくと如何にこの製品が世に出て良いクオリティに”達していない”かが理解できると思います。
・そもそも基本的なSMART情報すらGUIインターフェイスから取得できないんですけども。
こんな論外な製品ではありますが、使い続けてしまったのがまずの失敗でした。考えてみればこのTeraStationは買って約３年で、今回は通算HDD３本目のトラブルです。HDDの一般的な故障率から考えても故障が多すぎます。つまりTeraStaiton自体のハードウェアに問題があるのです。綺麗すっぱりHDDが故障するだけならここまでサルベージ業者が氾濫しないはずであり、私がこうやって書くのも気合いで何とかなるケースが多いからだと思われます。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ さて、本題 ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
・RAIDの基本的な知識は、wikipediaのRAIDの記事などを参考されたし。
＜環境＞
・TeraStation 1 (今回壊れた物、今後TS1と略す）：TS-XLシリーズ。1.5TB HDD x4, RAID5。社内のそれほど重要ではないファイルを保存するためのNAS。HDDの４本を上からHDD1, HDD2, HDD3, HDD4と略す。
・TeraStation 2 (今回は壊れていない。今後TS2と略す）：1.5TB HDD x4 Raid5。別プログラムにより、毎朝４時にTS1 -> TS2に同期コピー（クローン化）。社員はアクセスできず、基本的にTS1のバックアップとして保持。ポリシとしてはTS1が故障し、復旧出来なかったときの”１日”遅れのバックアップの為に設置。
＜経緯＞
7/16 正午頃：TS1のHDD4が故障と判断されアラームが鳴る。RAID5なのでこのタイミングでデグレードモード（縮退モード）に入る。その後の調査で、このHDD4は数百ブロック単位のセクタエラーが発生していた。Tera StationのOS（ソフトウェアRAID機能）が、そのセクタエラーに突入し一定時間アクセスできないため、HDD4を異常と判断し、デグレードモードに入ったと思われる。新規の1.5TBのHDDを購入しておいてので、この時点でHDD4を新HDD4に入れ替えて、RAID5のリビルドを開始した。
＊留意１）本来ならこのデグレードモードに入った時点で、ネットワークから切り離し（社員にアクセスをやめさせるため）、リビルドではなく、データのバックアップ（別のHDDにTS1のデータをコピーさせる）べきであった。RAID5の復旧作業では、ここでバックアップをとるのが、セオリーかと思われます。これは私のミスだと思っています。しかしNASがどんどん容量が肥大化し、すぐに4.5TBの外部HDDを用意するのも面倒だと思ってしまったのです。TS2のバックアップもあるしと当時考えました。
* 留意２）RAID5の構成上（当たり前であるが）デグレード状態からのリビルドは非常に時間がかかる。しかも最近の1.5TBなり2TBなりの大きさが当たり前の時代でのリビルドはもう１０時間程度では終わらないことを覚えておくべきである。
7/17 朝３時頃：TS1のリビルドが完了していない状態で、HDD3が故障。RAID5のデグレード中のリビルド状態で２本目のHDDが死亡した。つまりRAID5の理論通りであればこの時点でこのNASのデータは復旧不可能であり終了のお知らせである。深夜でありもちろんオフィスには社員が誰も居ない状況。
* 留意３）本来この時点でこのTS1はRAID5で２本HDD故障なので、本来アクセスできないはずである。しかし、出社直後の朝の状態でLAN内からは見えており、何となくアクセスできる状態であった。
* 留意４）冷静に考えれば1.5TB級のRAID5のリビルドは非常に時間がかかり、しかもその間４つのHDDがフル稼働になり相当熱も出る。その間にもう一本のHDDが死ぬことは、HDDの故障率より大幅にあがると考えるべきである。しかもHDDは同一ロットで、Tera Stationに使われているHDDは常時稼働を想定していない普通のHDD(エンタープライズHDDではない）であり、故障しやすいものを使っている。
7/17 朝４時：TS1 -> TS2のデータバックアップ（クローン同期）バッチが動作。
* 留意５）これは完全に私のミス。TS1がデグレードし、リビルドなどの緊急自体になっている以上、TS1 -> TS2のバックアップクローンバッチは停止すべきであった。１日前のデータは完全にTS2に保持されているため、7/16日のNASへのアクセス分だけ無効になるだけで済むからである。
7/17 朝４時：TS1 -> TS2のデータバックアップでファイルの消失が多数発生。先述の通り２本目のHDD3が死んだ時点でTS1へのアクセスが完全に遮断される仕組みであれば問題はなかったし。しかしTS1はHDD1, HDD2だけの不安定な状態でもネットワークに参加し続けていた。RAID5は３本以上のHDDでファイルの管理を分散管理しているが、そのフォルダ構造のみはHDD1, HDD2で保持できていたらしい。つまり朝出社してTS1のネットワーク共有フォルダにアクセスするとアクセルは出来るのにフォルダの中身が入っていないという箇所が見られた。つまり、HDD3に所属していたファイルが見えなくなっているという状態である。この状態で、朝４時にTS1 -> TS2のバックアップクローン同期バッチが動いたため、TS1のファイルが無くなったのをバックアップソフトがファイルが無くなったと判断しTS2のファイルを削除するという現象が発生した。これはやばすぎた。 これにより１日遅れたでもデータの大方を保持していたバックアップ用TS2のデータは完全ではなくなってしまった。
7/17 朝9時出社：HDD3も死んでリビルドが停止しているのを知る。TS2があるのでまだ冷静（笑）。自分のPCからそのTS1にアクセスしたところ、あれ？HDD1, HDD2しかないのにアクセスできるぞ？と疑問に思う。朝４時に働くバックアップバッチを停止していないことに気がつく。早速TS2を起動し（朝４時にバックアップが終わったら勝手に切れる）、中身を確認したところ、やはり一部のデータが失われている。この時点で血の気が引く（笑）。社員にTS2のデータを確認し失われたデータがクリティカルか確認したところ、大方問題はないが、やはり一部復旧できればありがたいという事。そこで、このTS1が復旧できないか可能性を探ることにした。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ 以上、トラブルの経緯。以下、復旧の過程 ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
・RAID5 = 2本以上HDDが壊れたら終了。それは基本である。どのTera Station 復旧・サルベージ業者もそう書いてあると思われる。しかしそこであきらめたら試合終了ですよ、である。そもそもHDDが２本連続で壊れるってなんだ？HDDの故障というのを、TeraStationのOS(ソフトウェアRAID機能）はどうやって判断しているのだろうか？
・TS1をとりあえず再起動してみた。するとmd2 (RAID5のデータパーティション）がマウント出来ないというエラーがでた。HDD1, HDD2しかないので、マウントできないのはあたりまえ。出社時にTS1にアクセスできていたのは、HDD3が死んでも、TeraStationとしてはmd2をマウントできていると錯覚しネットワーク上に共有フォルダを公開し続けていた（実際にはHDD3が死んでいるので、ファイルの一部にアクセスできなくなっていた）。Tera Station利用者は、RAIDが崩壊した際に、このような不安定な状態で稼働しつづけるという現象をよく覚えておくと良いであろう。不安定になったときにネットワークから自分で切り離す機能などはない。
・ここで、故障したHDD3（TS1に刺さったまま）をよく見てみるともちろんHDDのエラーとしてはでているが、触ってみるとモータは回っている。つまり最悪のHDDのモーター故障によるHDD死亡ではないことがわかる。実際にHDDのモーターが壊れるなんていうエラーは少ないのではと考えている。結果として、SMARTでチェックしたところHDD3, （取り外した）HDD4はセクタエラーによるリードエラーが発生している状態であり、まだ何とかアクセスはできそうな様相であることが分かった。ちなみに後で分かったことであるが、正常と思っていたHDD2もセクタエラーが発生しており、結果としてHDD2, HDD3, (取り外した）HDD4が同時期にセクターエラーを起こしていたことになる。恐ろしい・・・。何か他の要因があるとしか考えられないんだけども。あ、ちなみに熱環境ですが、特別ホコリに被っている状態でもなく、極度に暑い部屋に置いていたわけでもない。
・ここで冷静に考えると、HDD4が壊れてRAID5がデグレードモードに入ったわけである。リビルドという作業は、HDD1, HDD2, HDD3から（入れ替えた新しい）HDD4に復旧（再パリティ）する作業であり、HDD3の故障直前までは、HDD1, HDD2, HDD3が正常で、HDD4がリビルド途中による不安定な状態であると判断できる。つまり、HDD4は今回完全に無視し、HDD1, HDD2, HDD3で何とかRAID5のデグレードモードでマウントさせてデータを吸い出せないか考えた。というのは前述の通りHDD3はセクターエラーは発生しているが、何とかアクセスできるような状態であったためである。
＜以下、TeraStationからHDDを番号を間違えないように管理した上で取り外し、別のデスクトップＰＣで作業をした＞
・ここで、HDD3をセクター単位でコピーできるソフトを使ってまた別の新規HDD(2TB)にコピーすることにした。HDD3は1.5TBであったが、メーカーによってサイズが若干異なるため、明らかに大きなHDDにセクターコピーしたほうが良いためである。EASEUS Disk Copy Homeという無料でダウンロードできるソフトを用いてこの作業を行った。EASEUS Disk Copy Homeは、.iso形式でブータブルCD(DVD)を作成できる。そのCDでブートし、HDDをセクタ単位で丸ごとコピーできる。けっしてWindowsなどでHDDを無理矢理マウントしてはいけない。データが書き換わってしまっては終了のお知らせである。セクタ単位でコピーしたのは、HDD3にセクターエラーが出ているのは分かっていたので、人間の癌と同様にアクセスすればどんどんブロックが拡大していくセクタエラーを最小限に食い止めるためである。結果として新HDD3にセクタコピーが完了した。途中予想通り８ブロックでセクタエラーが発生していた。このブロックは何ともならんので、無視して飛ばしてコピーを続行した。この作業もあ1.5TBあるので８時間くらい掛かった。
＊懸念：（この時点ではHDD2にセクタエラーが発生していることを知らなかったが）HDD3にセクタエラーが８ブロック発生したことで、ここに所属しているはずのファイルがどの程度影響するのか心配ではあった。
・この時点で、正常なHDD1, HDD2 (後にセクタエラーがあることが分かる。しかも２００ブロック程度。HDD3よりも悪い状態であった）、コピーした新HDD3の３本でRAID5をマウントする作業を開始した。TeraStationは、何のことはないLinux + LinuxのソフトウェアRAID機能MDでRAIDを管理している。つまりLinuxのソフトウェアRAIDを使った方ならある程度扱うことができると思われる。私もRAID1はよく使っているし、最低限の知識はあった。
・今回はDVDブート(LIVE起動）のLinuxを用いて作業した。3本のHDDは、USB -> SATA変換（裸族とかいう製品）を用いてUSB経由で接続した。後から分かったことであるが、HDD1, HDD2, HDD3, HDD4は、それぞれTeraStation内で、/dev/sda, /dev/sdb, /dev/sdc, /dev/sddのデバイスファイルが割り当てられたことが分かった。LIVEのDVD Linuxで作業したのは、何かのHDD起動のLinuxだとそのOSが入っているHDDが/dev/sdaを取っている可能性が高く、いろいろ面倒かなと思ったからである。（結果としては得策だと思う）
・今回のデータボリューム(約4.5TB程度）のmd2パーティションは、それぞれ /dev/sda6, /dev/sdb6, /dev/sdc6で構成されていることが分かった。
・mdadm –examineコマンドで、各パーティションのMDスーパーブロックを確認してみる。MDのスーパーブロックというのは非常にキーになる項目であり、いろいろ調べていただきたいが、RAIDを構成しているパーティション（この場合は３つ：/dev/sda6, /dev/sdb6, /dev/sdc6)の後半部に、”そのパーティションは他のHDDとこのような状態でRAIDが組まれている”というような情報を保持しているデータ領域である。LinuxのソフトウェアRAIDが、このMDのスーパーブロックという仕組みを採用している理由は、たとえばあるLinuxサーバーにRAIDが組まれている時に、そのサーバのマザーボードが壊れるなり、RAIDとは関係のないOSが入っているHDDが壊れた場合などに、そのマザーボードなりOSを別の環境として構築した際にも、RAIDを構成している複数のHDDを持ってくれば、それぞれのHDDのパーティションのスーパーブロックの情報を読み出せば、このＨＤＤ同士でRAIDを組まれていたことが判定できてマウントすることができ、ある意味環境から独立していて障害に強いからである（らしい）。
＜以下に３つのパーティションのスーパーブロック情報をペーストする＞
>
> # mdadm –examine /dev/sdc6
> mdadm: No md superblock detected on /dev/sdc6.
> # mdadm –examine /dev/sdb6
> /dev/sdb6:
> Magic : a92b4efc
> Version : 00.90.00
> UUID : 16b11c01:a0a9825e:0470c5b9:91c14a48
> Creation Time : Sat Apr 18 04:53:29 2009
> Raid Level : raid5
> Used Dev Size : 1450031168 (1382.86 GiB 1484.83 GB)
> Array Size : 4350093504 (4148.57 GiB 4454.50 GB)
> Raid Devices : 4
> Total Devices : 3
> Preferred Minor : 2
>
> Update Time : Tue Jul 17 06:38:03 2012
> State : clean
> Active Devices : 2
> Working Devices : 3
> Failed Devices : 2
> Spare Devices : 1
> Checksum : e715a8a3 – correct
> Events : 18023
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> Number Major Minor RaidDevice State
> this 0 8 6 0 active sync /dev/sda6
>
> 0 0 8 6 0 active sync /dev/sda6
> 1 1 8 22 1 active sync /dev/sdb6
> 2 2 0 0 2 faulty removed
> 3 3 0 0 3 faulty removed
> 4 4 8 54 4 spare
> # mdadm –examine /dev/sda6
> /dev/sda6:
> Magic : a92b4efc
> Version : 00.90.00
> UUID : 16b11c01:a0a9825e:0470c5b9:91c14a48
> Creation Time : Sat Apr 18 04:53:29 2009
> Raid Level : raid5
> Used Dev Size : 1450031168 (1382.86 GiB 1484.83 GB)
> Array Size : 4350093504 (4148.57 GiB 4454.50 GB)
> Raid Devices : 4
> Total Devices : 3
> Preferred Minor : 2
>
> Update Time : Tue Jul 17 06:38:03 2012
> State : clean
> Active Devices : 2
> Working Devices : 3
> Failed Devices : 2
> Spare Devices : 1
> Checksum : e715a8b5 – correct
> Events : 18023
>
> Layout : left-symmetric
> Chunk Size : 64K
>
> Number Major Minor RaidDevice State
> this 1 8 22 1 active sync /dev/sdb6
>
> 0 0 8 6 0 active sync /dev/sda6
> 1 1 8 22 1 active sync /dev/sdb6
> 2 2 0 0 2 faulty removed
> 3 3 0 0 3 faulty removed
> 4 4 8 54 4 spare
・上記でわかりますでしょうか？新HDD3 (/dev/sdc6)のスーパーブロックがないのです！！故障HDD3 -> 新HDD3はセクタ単位でコピーしているため、パーティションの最後にちょこっと付いているスーパーブロックの領域もまとめてコピーされるはずです。それが何の原因か無くなっていました。デグレート状態のリビルド中にHDD3が死ぬとHDD3のスーパーブロックは削除されるのでしょうか？この辺は意味不明です。このあたりでだいぶやっかいな状態だと分かりました。個人的には、HDD1, HDD2, 新HDD3の３本でそのままmd2(RAID5)パーティションとしてマウントしちゃえば普通にアクセスできると思っていたので、まさかの状態。
・とりあえずHDD1 (/dev/sda6), HDD2 (/dev/sdb6)のスーパーブロックの状態を見てみます。この情報によると、以下のようなことが読み取れます。
１）RAIDのレベルは5である。
２）RAIDディスクは４本。トータルのディスクの数は３本。アクティブなディスクは２本。トラブっているディスクは２本。スペアのドライブは１本。なんだこれ・・。めちゃくちゃだ。スペアが１本ってなんぞやと。
３）MagicナンバーやUUIDなどもここでわかります。/dev/sda6と/dev/sdb6は同一なので、これはRAIDパーティションで共通なのがわかります。HDD3にもこの値が書かれていたはずでしょう。
４）RAID5の１番目のHDDは、/dev/sda6パーティションであり、”Active”で”Sync”している状態。Major = 8, Minor = 6であることが分かります。この情報からHDD1は、TeraStationで、/dev/sda6でマウントされていたことが読み取れました。
５）RAID5の２番目のHDDは、/dev/sdb6パーティションであり、”Active”で”Sync”している状態。Major = 8, Minor = 22であることが分かります。
留意）ここで各HDDのMajor, Minorという数字は最初わからなかったのですが、Linuxのソースコードを読んで分かりました。この２つの数字で、/dev/sdb6などのマウントポイントをしめしていることがわかりました。Major=8, Minor=6だと、/dev/sda6となります。Minorが、22だと/dev/sdb6になります。勘の良い人なら予想が付くでしょう。HDD3は、/dev/sdc6に割り当てないといけないので、Major=8, Minor=38だと予想できます。
・こんな感じでスーパーブロックが読み取ることができました。スーパーブロックは、上記の内容よりRAID5の構成、状態、各HDDの情報、そして自分はそのHDDのどれか？などの情報が含まれています。またRAID5でHDD4が死んでデグレード状態に入り、リビルド中にHDD3が死んだので、HDD3, HDD4がfaultyになり、HDD1, HDD2だけがActive Syncになっていてニッチサッチもいかない状況であることもここで分かりますね。
・さて、新HDD3は、MDスーパーブロック情報が欠落しているため、RAID5に参加できません。マウント（アセンブリマウント）させようとしても、RAID5なので最低３本ないとマウントできないため、”not enouigh to start the array.”というエラーが発生し、マウントできませんでした。HDD3を見つけられないのですね。
・そこで、HDD3(正確には/dev/sdc6パーティション）にスーパーブロックを手動で無理矢理付けてLinux側をだましてマウントできないか検討しました。
・スーパーブロックの直接の編集には、以下のサイトが非常に参考になりました。多謝。
・ここで公開されているソースコードを改変し（内容を理解しないと使えない）、HDD3に無理矢理スーパーブロックを付与することにしました。スーパーブロックをちゃんと理解するためには、おごちゃんの雑文のソースコードおよび、linuxのソフトウェアraidのソースコード（md_p.h)のmdp_superblock_s構造体に定義されているのでまずこれを読むと良いでしょう。というより、ここをちゃんと理解できないのであれば触るのは厳禁である。危なすぎて復旧できるものもできなくしてしまう可能性が高い。
例えば：http://lxr.free-electrons.com/source/include/linux/raid/md_p.h
などで。
・新HDD3のスーパーブロックの付与。設定したところを下記にちょいと解説。ウチの固有の情報なので参考程度に。間違えると失敗しますよ。あと、おごちゃんの雑文のコードは、あくまで書き込まれているスーパーブロックの変更・修正するプログラムであり、今回の様にスーパーブロックが消失しているパーティションに付与するには一部”おごちゃんの雑文”のコードを改変する必要があります。まぁその辺りを理解できていないとその後の作業が危ないので自分で考えてみて下さい。
nr_disks = 4;
raid_disks = 4;
active_disks = 3;
working_disks = 3;
failed_disks = 1;
spare_disks = 0;
state = 1;
events_loとevents_hiはHDD1, HDD2と同じ値を入れる必要がある（同じRAIDとして扱われない）
mdp_disk_tは適切に。mdp_device_descriptor_sに記述されている。配列になっていて、３番目のHDD3なのでdisk[2]が、HDD3相当になりますね。
number = 3;
major = 8;
minor = 38; // major = 8, minor = 38で、/dev/sdc6となる。
raid_disk = 3;
state = 6; // state = 6は、SA = Sync Active (つまりHDD3は問題なし設定する）
＊こんな感じかな。あくまで私の環境なので参考程度に。
・さて、次はHDD1, HDD2のスーパーブロックを修正。上のmdadm –examineでHDD1(/dev/sda6), HDD2(/dev/sdb6)を見ても分かるように、2つHDDがfailed diskになっているなど、HDD3, HDD4が死んでいるRAID5崩壊の状態になっている。そこで、上記のHDD3に付与したスーパーブロックと同様に、
nr_disks = 4;
raid_disks = 4;
active_disks = 3;
working_disks = 3;
failed_disks = 1;
spare_disks = 0;
state = 1;
以上で、RAIDの故障本数などの情報をHDD1,2,3で揃える。
そして、HDD3が故障という状態であるのそSync / Activeの状態に変更する。同じくdisk[2]に対して
number = 3;
major = 8;
minor = 38; // major = 8, minor = 38で、/dev/sdc6となる。
raid_disk = 3;
state = 6; // state = 6は、SA = Sync Active (つまりHDD3は問題なし設定する）
という感じでHDD1(/dev/sda6), HDD2(/dev/sdb6)に修正を施す。
・この時点では、もう一度mdadm –examineを/dev/sda6, /dev/sdb6, /dev/sdc6に掛けて、３つがRAIDの情報・構成が一緒で、各HDDの情報などが一緒であることを確認する。RAID5の４本構成で１本死んでいて、HDD1, HDD2, HDD3のデグレード状態であることを確認する。コツとしては、event, stateなどを3本揃えないとraidとして一つとして認識されないこと。またstate = 0になるとraidとして健全(active)になりうまくいかない。あくまで4本RAID5の1本死んでいる3本でのデグレード状態なので、RAIDとしては状態はactiveではない。その為super->state = 1;になる。
・さて、この状態でmdadmで３つのHDDをアセンブリしmd2をマウントし成功しました。
＊＊＊＊＊＊＊＊＊＊＊＊＊＊ マウント後 ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
・マウントに無事成功し、各ファイルは大方問題なくアクセスできることが分かりました。直ぐにネットワーク経由で別のNASにコピーしました。
・その際に、HDD2のセクタエラーの問題か、またはHDD3にセクタコピーした際に８ブロックほど無視して進めたのが問題か、コピー中に突然エラーが起こりファイルにアクセスできませんというエラーが発生しました。そうなるとまた直ぐにRAIDが崩壊してしまいHDD1, HDD2, HDD3のスーパーブロックが壊れてしまいました。なのでまた上記の方法で、スーパーブロックを書き直して、再マウントしました。これを繰り返し、大方のデータをコピーすることに成功しました。
＊＊＊＊＊＊＊＊＊＊＊＊＊ まとめ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
・繰り返しになりますがTera Stationの使用は再度Googleなどで検索してもらい、そのトラブルの数を確認してもらい、継続して利用するが良いか検討するべきだと思います。私は使いません。やはりデータは宝なので初期投資が大きくてもちゃんとしたNAS (特にHDDはちゃんとエンタープライズ向けのHDDを使うのが良いのかな？）
・今回はRAID5（４本構成）で２本トラブってもデータが復旧できましたという紹介ですが、これはあくまでHDDの壊れ方が、モーターの停止などではなくセクタエラー程度で、何とかアクセスできる状態であったというのが大きいです。どんなものでも２本壊れて復旧できるもではありません。
・Tera Stationは単純にLinuxのソフトウェアRAID MDを使ったものだけですのでその構造・仕様が分かっていれば今回のように無理矢理マウントなどの可能性があります。おそらくTera Stationの復旧・サルベージ業者は同等の事までやってデータを復旧してくれる業者もあると思います。1TBで10万円とか、かなり高額を要求される可能性がありますが。かなり業者が乱立しているのでまた価格競争も始まっているようです。実際には私のケースでもHDD3にスーパーブロックが消失するというトラブルさえなければ、比較的簡単にマウントできるので、その程度でビジネスをやっている業者も多いでしょう。少し出来る会社なら、スーパーブロックまで調整してアクセスしてくれる業者もあるかもしれません。私もこの程度なら今回かなり内容が理解できたので仕事を始められますね（やりませんが（笑））
・この記事の手法は、私が扱ったTeraStation TS-XLシリーズに関してです。最近は、Windows Storage Server版のNASもバッファローは扱っているようです。Windowsで管理されていたら、今回のようにLinuxのソースコードを読んで対応とかできないので手に負えないですね。LinuxのソフトウェアRAIDベースで動いているTeraStationの情報でした。
・個人的にはRAID5, RAID6ってどうなのかなと思いました。なにせ再構築が時間が掛かりすぎてその間にもう一本以上壊れる可能性って結構あると思うんですよね。その際にファイルが３本以上のHDDに分散管理されているってサルベージも複雑ですし面倒だなと。これだけ大容量HDDが安い時代なのでやっぱりRAID1（ミラーリング）か、非RAIDで、時間差バックアップでやるとかそっちの方が復旧も楽な気がします。どうなんでしょうね。
・当たり前過ぎますが、RAIDはバックアップではないので留意が必要です。私もその認識でTS2を用意してTS1を毎日１回クローンを掛けてバックアップを取っていましたが、今回のトラブルの様にRAID5が不安定に崩壊するとそのファイル欠損がそのままTS2にコピー（同期）されます。はっきりいって怖すぎます。やはり大切なデータは電気が要らない不揮発メディア（＝今はBlu-Rayでしょうか）に焼き込むのが良いですね。別のHDD(群）でコピーしていくってやはり通電が前提で、何があってもおかしくないなと個人的には思います。これだけ写真・動画でデータ量が増えていますので全部をメディアに落とすのは現実的ではないかもしれません。しかしドキュメントファイル、各種設計データなどはそれほど大きくないのでは？最低限そういうデータは定期的なメディアへの焼き込みが必須だなと痛感しました。はい。基本ですね。
・結果的にHDD2, HDD3, HDD4がセクタエラーを起こしていました。実はこのNASは今回のトラブルまでに２回HDDを交換しています。使用約3年でHDD5本がエラーを起こすってちょっと普通じゃない気がします。HDDだけの問題ではない気が・・・。
・そもそもTeraStationにおいてHDDの故障診断がどうなっているか非常に気になります。というのはHDD2,3,4がその後調査でセクタエラーが発生したことが分かっていますが、不良ブロックは正常と判断されていたHDD2はエラーとして認識しませんでした。これはその不良ブロックにアクセスしたときにリードエラーが発生しトラブルと認識されるのかと思いますが、これが非常に判定が難しそうですよね。別Linuxに接続しSMARTを掛けたら直ぐにエラーが検出できたので、TeraStationお使いの方はウェブ管理画面からSMARTの情報（見られるんでしたっけ？）で定期的に確認した方がいいですね。
この記事は私が遭遇したトラブルと対処した防備録であり、皆様の環境とは大きく異なる可能性が高いです。この情報を元にデータが壊れても一切責任を負いませんので、ちゃんと理解して行動してください。サルベージ会社に頼むのもありだと思います。業者選びも大変ですが。また、あくまでこの方法は私が採った手法であり、HDD3のスーパーブロックが欠落していてもmdadmの–forceスイッチあたりで無理矢理認識？とかできるような気もしますがどうなんでしょうか。調べてみると無理矢理認識させると”自動で再構築が始まる”とかいう情報が多くて、そもそも３本のHDDのデグレード状態で無理矢理マウントしてデータを引っこ抜くという方針だったので、今更RAID5を正常な状態にするつもりはありませんでした。そのあたりで挙動が読めないmdadmにより強制アセンブリなどはちょいと避けました（スーパーブロックを直接編集するのもイレギュラーだとは思いますが）
