あなたのデータが消えるとき

こんにちは。辻村です。お休みを満喫されたでしょうか？
パソコンなんてほとんど触ったことのない人は、「ああ、こうやって私たちのデータを守っている人がいるんだな」と知っていただきたい。データを守っている皆様には、意外とあっさりデータは消えますよ、そんなお話です。

はじまりは一つの警告だった

ある日あなたは、会社の業務データが入っているシステムから、スマートフォンに1通の警告のメールを受け取る。

「ストレージ装置に故障が起きました。
故障したドライブは disk-1 です。
スペアディスクの利用を開始します。」

夜中だった。スペアディスク（予備のディスク）を使っているなら無事にデータが再構築され、部品交換の件は明日にでもメーカーに連絡すればいいだろう。 そう思っていったん眠りについた。
ふと眠りにつきかけたころ、あなたはシステムからもう 1 通メールをもらう。

「ストレージ装置に故障が起きました。 故障したドライブは disk-2 です。
この RAID 構成には冗長性がなくなりました。
壊れたと思われるファイルは以下の通りです。」

disk-2 はミラーリングをしている disk-1 と対（つい）になる面（めん）に入っているディスクだ。２箇所に同じデータが書かれているから１つが故障しても安全なのであって、両方に障害が出ればデータは失われる。「まずい、復旧しないと」そうつぶやきあなたは重い体を起こして会社の PC を開く。

データがどこにもない

「このシステムはある業務データの保管先だと聞いている。 ディスク装置の故障を修理したら、バックアップから戻せばいい」 そう思ってあなたはバックアップを探すことにした。 このシステムに一番詳しいのは G さんだから彼に聞いてみよう。

あなた　「夜分すみません。 ○○システムのストレージに障害があったってメールが来ました。どうもRAID の冗長性もなくなっているので、バックアップから戻ししたいんです。手順書ってどこにありますか？」
Gさん　「え？何言ってるの？それアーカイブだよ…だからそれで本番が動いているわけじゃないけど…まずいな…保存の必要な昔の業務データが入っているんだ。」
あなた　「アーカイブって、これしかデータがないってことですか？」
Gさん　「一応災害対策の意味で遠隔地にもレプリケーションでコピーは取っているけど…通知来たのいつ？」
あなた　「30 分前です」
Gさん　「それじゃ、レプリケーションが走っているから災対側もデータが壊れたかもしれないね…。」
あなた　「他にバックアップは？」
Gさん　「僕が S さんに引き継いだときにバックアップを作らないとという話があったけどね。予算だか何だかの話しで確か止まっていた気がするよ。」

確認したところ、Gさんが恐れていたとおり、災害対策サイトのデータも壊れたファイルで上書きされてしまっていた。 Sさんに確認したところ、やはりバックアップは取られていない。 こうしてあなたのデータはなくなってしまった。

ディスクはこうして壊れる

ディスクの故障は機械である以上、HDD であれ、SSD であれ、避けることはできない。 問題はどうやってこの故障を判断し、適切に交換するかと言うことだ。

SSD は利用日数で管理

SSD はそもそもある程度寿命が予測できるので、ドライブの機種に応じて交換時期を知らせる仕掛けがシステムに備わっている場合がある。ただし、寿命予測をおこなうための基礎データを OS 側で取る仕組みがまだ標準化されておらず、SSD ドライブ毎にコードを書く必要があるとどこかで読んだように記憶している。
（再編集時の付記：本記事を書いた時点では上記のようであったが、現在は log pageというものを使ってある程度のデータがとれるようになっている。）

HDDには「半分故障」がある
HDD に関しては機種も多くもっと泥臭い。 まず、故障率だ。故障率としては、私は特別な理由がない限り 1 〜 2% 程度と思っていた。[1]
教えて頂いた論文では、1.85% （ベンダー名非公開）であるので、私が過去に某所の件で集計したデータはそんなに悪いデータではなかったと言うことと思う。[2][3]
壊れるパターンは、私の感覚で申し訳ないが、突然動かなくなるか、何だかエラーを出しつつも粘りながら動いていてある日突然使えなくなるかのどちらかだ。

同じ論文には壊れるまでにどれくらい正常な状態でデータが収集できたかと言うことで、同じようなデータが出ている。

論文で触れられている Group 1, Group 3 はそれぞれ論理エラー（メディアエラーなど）と write/read 時のヘッドのエラーと言うことで、ある日突然ポン、と落ちる。このエラーはシステムとしても明快なエラーなので対処しやすい。ログを見ている人間も同様である。

それに対し Group 2 は bad sector によるもので、徐々にダメになっていってある日ダメになる。これは、read/write エラーもディスク装置的にはリカバリー可能なエラーがあるためだ。 そして、リカバリーができたときにはエラーは報告されない。例えば、書くときに bad sector だとしても、代替 sector に書き込むことができれば、管理情報に元のセクターが利用不可である旨を記録し、代替セクターに書いて次にすすむだけだ。 このため、書き込み性能が一時的に劣化したようにみえるけれども、書き込める。 代替セクターを使い果たしたときに初めて write エラーを返すので、そこまで OS 側から通常の I/O で知る方法はない。

読みだしについても同様で、内部でリカバリをして動いている間は OS 側から通常の I/O で知る方法はない。私が「半故障」と名付けているディスク装置は、残念ながらこういったリカバリで何となく動いてしまう。 そのため、壊れかかっていることが検出されない。そのくせ応答が悪くてそのうち 再試行可能な SCSI エラーを量産することになるので、性能劣化の片棒を担ぐことになる。また、こういうディスクが障害発生時にミラーの反対側にいたりすると悲惨である。

データロスを防ぐには？

読み書きしないとわからない故障がある

ディスクはいろんな壊れ方をするが、実際に読み書きをしてみないとわからない。[5] 従って、各社、データを壊さない非破壊検査の仕組みを用意している。データが壊れない形で読み書きしてメディアとして大丈夫かをチェックする検査だ。各社おのおの名称が違うが、media scrub や media scan と言った用語で、呼ばれている。

通常の read では使われないブロックが出てしまうので、scrub のように実際の I/O のパターンに関係ない全検査を定期的に実施することは大切である。

半故障を見つけるようにする

半故障は、しばらくエラーが出てまた収まっての繰り返しである。このようなパターンを見たら、メーカーに一度相談するとよい。もし半故障であるなら、早めに交換した方が良いかもしれないからだ。

RAID にもバックアップが必要と心得よ

「RAID 装置は冗長性があるからバックアップは不要」とか「レプリケーションを取っているからバックアップは不要」と思っていらっしゃるなら思い直していただきたい。理由は以下の一点につきる。

「コンピュータは、人間の目からみて誤った操作だとしても、指示されたとおりに動く」

うっかりやってしまったファイルの削除、プールの破壊[4]、壊れてしまったデータのレプリケーションと言ったことを防ぐことはできない。これは、誤っているということを知るのは人間だけだからだ。[6][7]

======
参考文献など：

1. ↑ 特別な理由とは洪水の後の泥で空気が汚染されていてクリーンルームでも粒子の数が多いとか、生産ロット不良があるとか言うことである。
2. ↑ @ogawa_tter さんには以下の論文を教えていただいた。この論文は、平時の SMART のデータから HDD の故障を予測しようとするものである。 Characterizing Disk Failures with Quantified Disk Degradation Signatures: An Early Experience by Song Huang, University of North Texas, Song Fu, University of North Texas, Quan Zhang, Wayne State University and Weisong Shi, Wayne State University
3. ↑ @gogotea3 にご指摘いただいたので加筆しておくと、SMART のデータは SATA のドライブだからできる方法だ。@ogawa_tter さんに教えて頂いた論文も SATA の SMART に基づいた方法である。SAS-2 のドライブを使っている現在では、実際には同様な情報を log page などからひろっており、収集の方法が少し違う。
4. ↑ これは簡略化した書き方で実際には RAID 装置や RAID の管理をおこなうソフトウェアにはプールの破壊につながる操作を禁止するような仕掛けが組み込まれている。
5. （編集時に関係がないので削除した）
6. ↑ レプリケーション元のシステムで異常が出ていればレプリケーションは自動停止するべきと言うご意見もあると思う。その通りであると思う。私は同意する。 (2015.11.11 加筆) 弊社内で確認した所、「ZFS のソースでチェックサムの異常があるブロックやメタデータの構造に問題が発見されてような場合、zfs send は失敗するため、ターゲット側で壊れたデータを受け取らないようになっている」というコメントをもらった。
7. ↑ 同様に、スナップショットもバックアップではない。