“超特殊”ファイルシステム「ZFS」がデータ復旧するまで

　企業において、サーバー上の重要なデータを失うことは、取り返しのつかない損害に直結する。その対策の1つとして、RAIDによるディスクの冗長化や、不整合が起きないように工夫されたファイルシステムなどが利用されており、そこに新しい技術も登場している。

　2004年にサン・マイクロシステムズ（現オラクル）が発表したファイルシステム「ZFS」もその1つ。ZFSは、それまでのファイルシステムの仕組みや構造を捨て、一から作り直されたファイルシステムだ。

　膨大な容量への対応や、ディスクを足すだけで既存のファイルシステムの容量を増やせる仕組み、二重三重に整合性が守られる構造などのメリットがある。主に大規模な企業サーバーのSolarisで使われているが、比較的新しいファイルシステムということもあり、導入企業はまだわずかと言われる。

　今回、“超特殊”なZFSの障害からデータを復旧させることに成功したという「日本データテクノロジー」（サイト名は「データ復旧.com」）を訪問し、エンジニアを務める西原世栄氏にデータ復旧までの道のりを聞いた。

●導入事例はごくわずか、ZFSとは

西原世栄氏

　西原氏はZFSを「まったく新しい概念のファイルシステム」と語る。まずZFSでは、今までのようにディスクをパーティションに区切って直接ファイルシステムに利用するのではなく、一度「ストレージプール」という形に抽象化して扱う。

　ストレージプールとは、複数のディスクやパーティションをまとめて1つの仮想的なディスクのように扱えるようにした単位だ。そのストレージプールの中を、パーティションのように複数のファイルシステムに分け、OSから利用する。パーティションとは違い、1つのファイルシステムでは決まった容量を持たず、ストレージプール全体の容量を複数のファイルシステムで分けて使う。

　複数のディスクを1つのストレージプールにまとめるときに、ZFSでは一種のソフトウェアRAIDである「RAID-Z」という技術を利用できる。通常のRAIDは、一度組んでしまった後は、ディスクを追加するには最初から組み直す必要がある。それに対してZFSでは、後からディスクを追加してストレージプールの容量を増やすことができ、その結果ファイルシステムの容量が自動的に増えるという特徴がある。

　なお、RAID-Zでまとめた単位をさらにストライピングして1つのストレージプールにする機能や、SSDをファイルシステムのキャッシュとして使う機能なども標準で備えている。

　そのほか、128ビットのアドレス管理により理論上16エクサバイト（1エクサバイトは100京バイト）の容量まで対応することや、ファイルシステム全体のスナップショットを瞬時にとる機能など、今までになかった機能や構造をたくさん持ったファイルシステムだ。それでありながら、一般ユーザーとして利用するぶんには、従来のファイルシステムと変わりなく利用できる。

　それだけの利点を持ったファイルシステムだが、新しいこともあって導入例はまだ少ない。同社でも、年に2万件の復旧依頼を受けているうち、ZFSの復旧はまだ数件である。

　これは、「対応OSがSolarisやFreeBSDの新しいバージョンに限られること」「主な対象である企業システムでは実績の少ない技術が導入しにくいこと」「すでにあるシステムのファイルシステムを変更することは滅多にないこと」などが理由として考えられる。また、ZFSが壊れにくいことが復旧依頼の少なさになっているのかもしれない。

●復旧の依頼は24台のディスク搭載のサーバー

　西原氏はZFSの第一印象として、「これは壊れないだろう」と思ったという。ZFSでは、データの変更もコピーオンライト（ブロックを一度コピーしてから書き換える方式）によるトランザクション処理となっており、書き換えが完了しないと変更が反映されないようになっている。これにより、書き換え途中に障害が起きても変更前の状態として整合性が保たれる。また、ストレージプールをある程度修復する機能なども備えている。

　「でも、壊れにくいだけで、壊れることはあります」と西原氏。同社でも実際にZFSの復旧依頼を受け、それまでに経験のなかった新しいファイルシステムの解析に挑戦した。復旧対象は、ディスクを24台搭載したサーバー。「大手SIerの優秀なエンジニアが修復できなかったため、ディスク復旧の専門家である我々の出番となりました」（西原氏）。

　復旧はまず、ZFSの構造や特性、壊れ方を研究するところから始まった。そのために同じ機種のサーバーも購入。そして、障害のあるディスク24台をコピーしてクローンを作り、クローンから作業用コピーを作って解析した。

　ディスク24台を搭載しSolarisが動くようなサーバーは値段も高価であり、店舗で売っている製品でもないが、西原氏は「弊社は技術投資に力を入れています」と言う。ほかの案件でも、サーバーに搭載された18台のディスクが特殊なモデルだったため、契約が正式に決まる前にディスクを買いに走って調査したこともあったという。

　ファイルシステムの復旧には多く知識と症例の経験が必要とされるため、新しく希少なファイルシステムの復旧は難度が極めて高い。「それまでに触ったことのないファイルシステムでしたから、どこから手をつけていいかわからない。まずは海外の文献や講師から情報を得て、ZFSの構造を研究しました」と西原氏は振り返る。

●ディスクの管理情報を16進ダンプで追う

16進数のバイナリデータ図。EXT4のファイルシステムの情報を表している

　西原氏は、16進数が並んだ図を見せ、「これはEXT3というファイルシステムでパーティションの先頭にある、スーパーブロックやPBRと呼ばれる管理情報です」と説明する。ディスクの論理障害で、ディスクの先頭にあるパーティションテーブル（どこからどこまでを1つのパーティションとするかという一覧情報）が壊れたり消えたりすることは多いという。その場合には、ディスクの中に多数あるセクタの中からスーパーブロックを見付け出すことで、パーティションの先頭がわかり、そこからファイルシステムの構造をたどれる。

　同社でふだん論理修復をしているファイルシステムは、EXT3/4やXFS、NTFSなどが中心だ。「これらのファイルシステムなら、弊社のエンジニアは誰でも、各セクタの16進ダンプを見ただけでスーパーブロックを見つけられますし、ファイルシステムの種類もわかります。不整合も手動で直せます」と西原氏は言う。

　西原氏によると、スーパーブロックをはじめとするディスクの管理情報には、英単語として意味を持つ文字列が含まれている。わかりやすい例としては、NTFSのPBRには「NTFS」と書かれているそうだ。それらの文字列などを目印にディスクから検索することで目的の管理情報を見付け、この管理情報をたどってファイルシステム全体の構造を把握している。もちろん、それらの情報が壊れていることも多いが、テキストの文字化けのように壊れ方のパターンも把握しているという。

　扱ったことのないZFSについては、そうした経験がない。まっさらのZFSに解析用のデータを入れて、データの配置や切れ目などを調べたりもした。「コロンブスの卵と同じで、わかってしまえば当然なことに、なかなか気付かない。結局、復旧のカギもたまたま見付けたようなものです」。

　症状としては、ZFS上のRAID情報とファイルシステム情報の両方が壊れていた。それらを修復して無事データを吸い出した。依頼から納品まで2～3週間だった。「弊社にとっては、2～3週間かかるというのは異例の長さですね」と西原氏。ZFSの構造の調査にかかった時間が多かったため、次回は少し短くなるが、それでも5日はかかるという。「壊れ方はそれぞれ違うので、復旧事例の蓄積がないと難しい。ほかのファイルシステムなら、ほぼすべての壊れ方を経験しています。もっとZFSの復旧事例を増やして経験を積みたいですね」。

●RAID6も復旧実績を積み重ねる

RAID5とRAID6のイメージ。A～Dはデータが分割されて入っている様子を表している。PとQはパリティ

　比較的新しいディスクの冗長化の技術としては、RAID6もある。よく使われているRAID5では、ディスクを容量より1台多く使って冗長化し、ブロック単位のデータとそのパリティ（訂正情報）をディスクに分散することで、どの1台に障害が起こっても残りのディスクからすべてのデータを取り出せる。RAID6は、ディスクを容量より2台多く使い、パリティを二重化してそれぞれ別のディスクに分けることで、2台まで障害が起こってもデータを取り出せるようにする方式だ。

　「ただし、RAID6はRAID5より複雑なので、壊れたときの復旧の難易度も上がり、復旧会社を選びます。簡単なツールを使っているだけの復旧会社ではRAID6に対応できません」と西原氏は自信のほどを見せる。

　最近では、コンシューマー向けNASでもRAID6に対応するものが出てきた。これらの製品はソフトウェアRAIDを使っているが、「ソフトウェアRAIDは、ソフトウェアのバージョンによって、ディスクに書き込まれるRAID情報の位置が違ったりします。同じ機種でも製造時期によって変わっている場合があるので、復旧会社がそうした知識を持っていないと、RAID情報が壊れていると誤認する可能性もあります。単純な障害が他社で直らなくて弊社に持ち込まれる事例もよくありますが、こうしたことが原因の場合もあるようです」。

　なお、メーカーによってはソフトウェアに改造を加えていて、前述したような管理情報に含まれる英単語が違っているものもあるという。「最初見たときには、どういう壊れ方をしているんだろうと驚きました。このメーカーの製品についてはもっと事例を蓄積したいですね」（西原氏）。

先日まで研究していたという日立製サーバー

　よく使われているRAIDは、同社に持ち込まれる事例ベースで見ると、RAID5が圧倒的に多く、続いてRAID1とRAID10、まれにRAID0もあるという。お勧めのRAIDを聞くと「企業のサーバー用途なら、RAID6、5、10の順ですね。ただし、用途や本数にもよります。例えばRAID6は3本から組めますが、それならRAID1のほうがいい」と西原氏は答えた。

　RAID1はミラーリングなので、2台なら2台のディスクに同じデータが書き込まれており、両方が壊れていても、場所が違えば、それぞれ無事な部分を吸い出して1本にマージできる。ただし、西原氏が遭遇した事例で、RAID1の片方のディスクに障害があるのに気付かず使っていて、もう1台が壊れたときに復旧を依頼されたケースがあったという。「2台でファイルやタイムスタンプがあまりに違っているので、最初、どういう壊れ方なのか悩みました」（西原氏）。

　類似の事例で、1台のディスクに障害があったものが、何かのはずみで生き返り、そこにあった古いデータのほうが新しいデータの入ったディスクにミラーされてしまったケースもあったという。RAIDで冗長化している場合でも、ディスクに障害が起きていないかどうか、ときどき確認しておく必要があるだろう。

　RAIDやZFSのストレージプールと同じように、複数のディスクを束ねて使う技術としては、LinuxのLVM（Logical Volume Manager）やWindowsのLDM（Logical Disc Manager）もある。同社にも週に数件、復旧依頼が来るとのことで、西原氏によると「RAIDより修復に少し手間がかかる」という。データの開始位置がディスクの頭からではなく可変なため構造が複雑になるのだそうだ。LDMは、Windowsのディスクの管理の画面からよくわからないで選んでしまったりする人もいるため、ユーザー自身にも使っていることがわからないことも多いそうだ。

　このようにさまざまな技術が使われていても、ディスクの障害でデータが読み出せなくなることはある。対策法として西原氏は、UPSの利用とバックアップを挙げた。「バックアップはミラーリングでは駄目です。物理的に別の媒体に、できれば手動でバックアップしていることを認識したうえで取ってください」とアドバイスしてくれた。