ZFSの復旧に成功した「日本データテクノロジー」の研究チームとは
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/top.jpg)
東京・銀座に社を構えるデータ復旧会社「日本データテクノロジー」が、特殊ファイルシステム「ZFS」の復旧に成功したそうです。日本データテクノロジーは、他社に先駆けて自社内にデータ復旧専門の研究チームを設けており、今回のZFS復旧成功もこの研究チームの成果ということで、データ復旧の研究とはいったいどんなものなのか、その実態を聞いてきました。
データ復旧|PC・サーバー・RAID機器のHDD復旧ならデータ復旧.com
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/Snap684.jpg)
銀座にある日本データテクノロジーの本社に到着。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/P1420214_m.jpg)
「日本データテクノロジー」はデータ復旧のブランド名で、運営会社はOGID株式会社です。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/P1420224_m.jpg)
インタビューに答えるのは、日本データテクノロジーのデータ復旧事業部復旧技術チームに所属する、西原世栄さん。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/P1420228_m.jpg)
GIGAZINE(以下、G):
今回は、これまで復旧の事例が無かったと言われるファイルシステムで、ファイルシステム自体がRAID機能を持つ「ZFS」の復旧が可能になったとのことですが、まずは基本的なところとして、「RAID」というのはどんなものなのか、教えてください。
日本データテクノロジー データ復旧事業部 復旧技術チーム 西原世栄氏(以下、西原):
RAIDというのは、そもそも通常は1台のハードディスク(HDD)で運用しているものを、複数台のHDDを組み合わせて、仮想的な1台のHDDとして運用する技術のことです。その目的はさまざまで、大容量化、冗長性の確保、スピードアップなどが考えられます。
その中でも一番大事にされているのはやはり冗長化で、昨今のデータの事情を考えると、やはり1台で運用するよりも、複数本を使って1台が壊れても大丈夫な状況を作っておいたほうが安全と考えられます。RAID6であれば2台壊れても大丈夫になりますし、システムの冗長性を確保するという目的が、今のニーズとしては一番高いのかなと思っています。
G:
RAIDの目的は冗長性の確保ということですが、前回の話だと、結局RAIDというのも必ずしも安全ではなく、時には停電などで簡単に壊れてしまうこともあるということでした。基本的な話になりますが、RAIDの復旧依頼の中で、どういう原因で故障してしまうものが多いのでしょうか。
西原:
物理的なディスクの損傷か論理的な障害かで、大きく2つに分かれます。論理的な障害で言うと、例えばファイルシステムが壊れてしまうなどですね。物理的な損傷には季節変動のものありまして、例えば夏場ですと、HDDの裏についている緑色の基盤のチップが熱での劣化によってショートして、焦げてしまったりすることもあります。夏場は論理障害も増えますが、それは気温上昇だとか熱というよりも、夏場に発生する雷などで停電することによるもので、データを保存する度にパリティの計算をするようなRAID5の場合などは、計算途中で電源が落とされるとそこで整合性が取れなくなるので、使えなくなってしまうことがあります。
G:
今回、新たにZFSが復旧可能になったということですが、簡単に言うとZFSとはどういったシステムになるのでしょうか?
西原:
簡単に言うと従来のHDD、例えばRAIDなら、HDD3台~4台で構成されていて、そこに後からディスクを追加するというのは非常に難しい作業になります。ZFSに関しては、そもそもの設計思想が従来の面倒なHDDとは違い、例えるならメモリの増設のように、簡単に電源を切ってパソコンを開けて、メモリを差せば、それで増設されて、パソコンの性能がよくなるというようなイメージで、本数の追加が出来るという設計思想のもとに作られたファイルシステムです。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/P1420266_m.jpg)
G:
今までRAIDを作る時は、最初に4台で運用しようと思ったらずっと4台で運用しなくてはいけなかったけれども、ZFSでは、後から本数の追加ができるということですね。
西原:
ZFSは容量の制限もほとんどありません。ZFSは「Zettabyte File System(ゼタバイト・ファイル・システム)」の略で、ゼタバイトというのは、1テラの10億倍ほどの容量で、基本的に容量オーバーになることはない、ということを示しています。2004年ころから使われるようになったシステムで、ファイルシステムとしては非常に新しいものですね。
G:
ZFSには容量の制限がないということで、かなり大きな企業などで使われるのかなというイメージがありますが、具体的にはどのようなところで使われているのでしょうか。
西原:
当然大規模なデータセンターでも使われますが、従来のLinuxのファイルシステムに比べると、比較的容易にRAIDの構築ができるという特徴も持っているので、個人でも使う人は増えているようです。
G:
ZFSというと、UNIXの次世代ファイルシステムということで注目を集めていて、FreeBSDに移植されたり、Redhat Enterprise Linux 6 BetaにZFSをネイティブにインストールを行う人もいると聞きますが、そういったデータも復旧出来るのでしょうか? また、仮想化サーバの復旧は可能なのでしょうか?
西原:
そういうデータも復旧できます。また、仮想化に関してはいろいろあるのですが、メーカーとして取り組んでいるクラウドの仮想化みたいなものに関しては非常に難しいです。仮想化したサーバーを復旧できるということはイコールで仮想化したサーバーを構築できるということになってしまうので、そこは難しいですね。ただ通常の仮想化サーバーなら、そのファイルシステムも少し特殊なバーチャルマシンであるVMware用のファイルシステムが使われていたりするんですが、そういうものであれば通常フローでHDDも直せるようになっています。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/P1420261_m.jpg)
G:
今回新たに復旧が可能になったということですが、どういったきっかけで復旧ができるようになったのでしょうか。
西原:
新しいファイルシステムということで、まだ本格的に導入している企業も多くないため、問い合わせ件数自体が少なかったのですが、今回、大規模なRAID復旧の依頼があり、それがたまたまZFSだったんです。お客様の大変重要なデータだということでしたが、復旧の事例が無いファイルシステムだったので、復旧事例は無いがぜひ挑戦させて欲しいということで、ファイルシステムの解析をしつつ復旧を行い、無事データの復旧に成功したのがきっかけです。
今回復旧したのは、HDDが24台。直し方としてはまず、持ち込まれたものと同じディスクを用意して、一旦お客様のデータをクローンしたんですね。そのクローンしたディスクを自分たちでいろいろいじりながら「このセクタの情報が書き換わっている」という部分を発見し、その変更によってどういう障害が発生するのかということを、ひとつずつ検証していきました。これで復旧事例ができましたので、これ以降はZFSの復旧を通常のRAIDと同じように行えるようになりました。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/P1420235_m.jpg)
G:
「復旧事例がある」ということがデータ復旧の業界では重要になるようですが、一般的にはちょっとイメージがしにくい感覚があります。復旧事例があるのと無いのとでは、それほど違うものなのでしょうか?
西原:
復旧事例が無いということは、病院で言えば未知の病気を治療するようなもので、いったいどこが悪いのかすら分からない状態です。薬を投与するにも、どんな薬を投与していいのか分かりません。それが、復旧事例があるということは、どんな病気なのかが分かっていて、どんな薬を投与すれば治るのかが分かっている。それくらいの違いがありますね。
G:
なるほど。今回新たにZFSを復旧する上で、従来のファイルシステムと違って困難だったところだとか、苦しんだというようなところはありますか?
西原:
日本データテクノロジーはどんなファイルシステムでも基本的にソフトに頼った復旧はしないのですが、今回は特に情報がまったく無いので、ディスクをひとつひとつ内部解析して、全てのセクタの情報を見て、まずファイルシステムの特徴を理解することが必要でした。従来のファイルシステムであれば、過去の復旧事例から壊れた箇所の特定の仕方だったり、壊れたセクタが「大体この辺だろう」というのは分かるものなんですね。しかし、ZFSはまったく情報が無いので、例えば、ZFSのブートをするセクタがどの辺にあってだとか、多分RAID情報はこの辺にあるとか、ファイルシステムの構造上の問題から取り組まなくてはなりませんでした。
G:
どのデータがどの部分にあるかが、まず分からないということですね。
西原:
ファイルシステムを構築するデータが、どのセクタにあるのかが分からないので、そこをまず割り当てるのに非常に時間が掛かりました。
G:
開発しているところに聞けば分かるというものではないのでしょうか?
西原:
分かると思いますが、ファイルシステムのような大きなプロジェクトに関しては、直接開発に聞くというのは非常に困難なので、やはり自社で研究するしかないですね。あとは海外のファイルシステムの専門家たちが研究した論文などを見て、ファイルシステムの構造を推測していきます。
新しいファイルシステムについてもそうですが、過去に存在していて今では使われていないファイルシステムというのも、依頼が入ってくる場合があります。非常に古いサーバーだったりして、例えば先月か先々月に入ってきた依頼では、ヒューレットパッカードのサーバーでアルファファイルシステムという、今はもう使われていないファイルシステムでした。それもやはり復旧事例が無くて、見た瞬間に「ちょっと普通じゃないぞ」と。そうなってしまうと、まずは英語版のWikipediaから検索して、このファイルシステムはいったいなんだというところから始まります(笑)
G:
HDDだけで送られてきてしまうと、それがどんなファイルシステムを使っているか分からないということですね。
西原:
10年以上も使っているというサーバーだったので、お客様も「動いていたけどよく分からない」という状況でした。やはりそれもひとつひとつセクタを分析していって、ぐちゃぐちゃの英数字の中からところどころ、英単語のような単語があるので、それをひとつずつ検索していくんですね。それがヒットしたら、そこから掘り下げていって、ファイルシステムっぽいところにたどり着くと「ああ、こういうファイルシステムの名前なんだ」という、本当にそういう運頼みという部分もあるんですね。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/P1420251_m.jpg)
G:
実際に壊れたHDDの中の状態を見たことがないので、ちゃんとイメージができないのですが、どのように表示されるのでしょうか?
西原:
バイナリエディタのイメージですね。
G:
英数字がバラバラ並んでいるような感じですね。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/001_m.png)
西原:
HDDの中身を16進数で表示すると、ズラッと数字が並びまして、その16進数を変換したアスキーの文字列で見ていくのですが、基本的にはぐちゃぐちゃなんですね。その中でところどころにキーになる文字がぽつぽつとあるという状態です。ある作業を行うと、所々に「ん?」と思うようなポイントが出てくるので、それを全部検索にかけて探していくという、非常に地道な作業を行います。
G:
「ん?」と思うようなポイントがここに出てくるということは、ここはこういうシステムが入っているんだろうなというのを探り当てていく作業であるということですね。今回もそういった地道な作業を繰り返していって、ZFSがどんな様にできているのかなというのを探っていったということですが、それができるような施設や研究チームを持っている復旧会社でないと、そもそもそういった取り組みをすることができないということでしょうか?
西原:
そうですね。
G:
ちなみに業界的にはそういった研究チームや研究施設を持っているところというのはどれくらいあるものなんでしょうか?
西原:
わかりません。当社が提携している海外の復旧会社では研究開発部門がありますが、日本ではあまり聞いたことがないです。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/P1420245_m.jpg)
G:
今回のように新たなファイルシステムの案件が舞い込んできたような時以外は、研究チームの人は何をしているのでしょうか?
西原:
物理、論理ともに、常に課題というのはあって、復旧困難な障害に取り組んでいます。
G:
新たなファイルシステムが出てきて、事例も何もない状態なので復旧できないというのはなんとなくイメージできますが、それ以外に復旧困難な論理障害というのはどんなものなんでしょうか?
西原:
一番難しいのは、やはりお客様でHDDを入れ替えてしまうものが難しいですね。
最近入ってきたRAID復旧の依頼で、4台のディスクがあって、その4台をまるまるお客様がバックアップを取っていたという事例がありました。これはミラーリングではなくて、ただのデータのバックアップなんですね。メインのサーバーが1台おかしくなって、お客様がいろいろいじったけれども直らなかったそうです。それで、バックアップした同じ筐体があるので、HDDを4台抜いて、いったん全部こちらに突っ込んでみようと考えたそうです。ドライブ側の端子の接触不良とかの可能性もあると考えたんですね。それで、4台全部入れ替えて動かしてみたのですが、やはりファイルシステムの内部の問題で、動かなかった。
そこで、そのままの状態で持ってきていただければ100%すぐに直るんですが、今度はバックアップ側の1台を、壊れた1台と入れ替えたそうです。実は、こうしてバックアップを取ったデータというのは、中のデータとしては同じなんですけれど、16進数上のデータで言うと全然違うものなんです。RAID1の場合はセクタ単位でコピーするんですが、通常のファイルの移動の場合はブロック単位でのコピーになるので、セクタが完全に同じにはならないんですね。データは同じなんだけれど、バイナリ上は違う。それなのに、壊れた1台とバックアップの1台を入れ替えても動かないので、「じゃあ、他の何が違うのか」といって何度か入れ替えたりした、と。最終的にはこの4台とこの4台がセットだということすら分からない状態になって、「8本で2組です」ということで持ち込まれる形になりました。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/P1420274_m.jpg)
G:
元の状態がまるで分からないということですか。
西原:
それは研究チームがその課題を共有して直しました。
G:
何とかなるものなのですね。
西原:
直りましたね。ただ時間は普通のものより掛かりました。
G:
素人では抜き差しすれば直りそうなものだなと思ってしまうところですが、そういうところで二度と直らなくなる可能性もあるということですね。
西原:
そうですね。知識のあまりない技術者やサーバーを管理している方が直そうとして色々いじってしまったRAIDはやはり復旧が難しくなりますね。
G:
研究チームがあるというのは、困難な事例に時間を掛けて取り組むことができるということでもあるというわけですね。ちなみに物理障害の研究によって新たに直るようになるということはあるのでしょうか?
西原:
ありますね。例えばファームウェアというHDDを動かすためのプログラミングがありまして、そのファームウェアが壊れてしまった際にどういう直し方をするのかというのは研究していますね。これもバイナリデータを見ながら、この数字はどういう意味を示しているのかとか、この数字がHDDにどういう信号を与えているかというところの研究を、自分で数字をいじって、どういう動きになるのかを試し、研究しているという感じですね。物理は幅広いので、部品の交換とか、壊れたHDDにどの新しい部品が合うのかというところから始めなくてはいけないんです。そういう研究は常日頃から行われていますね。モデル名は同じだけれど、部品の互換性はなかったりだとか。そういうところの研究は必須ですね。
G:
RAIDの復旧事例だと、ZFSのほかに特に困難だった事例などはありますか?
西原:
難しさのレベルでいうとRAID6ですね。
G:
RAID6とはいうのはどういうものなんでしょうか?
西原:
HDDが2台壊れても大丈夫なように、残りのディスクでその2台の情報を持つという形式です。
通常の3台のRAID5だと、使える総容量は2台分しか使えません。残り1台はパリティだけに使う容量です。これに対して、RAID6というのは、例えば4台で組んだ場合に、2台でパリティの情報を持ち、残りの2台で実データを持ちます。HDD自体は4台ありますが、2台分のデータしか使えない代わりに、残りの2台分の容量で、全てのデータの構成の計算式を持つんです。だから1台目と3台目が壊れても、残りの2台で全て持っているので大丈夫という形ですね。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/P1420292_m.jpg)
G:
復旧時に難しいのはどんなところでしょうか。
西原:
やはりパリティの計算が難しいと思います。パリティの計算というのは、RAID5なら、データがこのように分散されます。Pがパリティで、1、2というのは保存されているデータの数値です。2が壊れても1とPという計算式から2を導くことができます。単純なプラスマイナスの計算ですね。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/Snap705.png)
西原:
RAID6というのはこれが二重構造になっていて、こうした形になります。この場合、PとQがパリティですね。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/Snap706.png)
G:
パリティが2個あるということですね。
西原:
はい。16進数をアスキーの文字列に変換した段階では、この図ほどはっきりとは見えないので、ここの分析ができないとRAID6は絶対直せないです。見てもRAID5にしか見えないんです。
実際に文字列で見る時は、データの部分もぐちゃぐちゃで、パリティの部分もぐちゃぐちゃですが、そのぐちゃぐちゃ具合から、ここは実データで、ここはパリティだというのが分かるんです。詳しいことは技術漏洩の観点からあまり言えませんが、ここは恐らく2つのパリティだということで「これはRAID6だろう」と推測ができるわけです。
G:
ノウハウがあるので、「この構造はRAID6だ」と判断がつくということですね。やはり自社内で復旧事例を重ねていかないと分からないということでしょうか。
西原:
そうですね。RAID6は自社内で事例を重ねていかないと難しいと思います。RAID6を使うようなところになると、やはり非常に大きな規模のところなんですね。弊社は官公庁や大企業様から数多くのご依頼をいただいていますので、自然にうちに来てうちが直すという流れもあります。その分、他社さんに比べてノウハウの蓄積スピードも速くなっているという側面もあります。
G:
官公庁からも復旧の依頼が来るものなんですか?
西原:
はい、それ以外にも上場企業様からのご依頼も多いですね。
G:
どんなファイルシステムを使っているかという部分にもよるかと思いますが、大きなところになればなるほど、復旧困難な事例は増えていくのでしょうか?
西原:
そうですね。データサイズが大きいですし、重要性もありますので、セキュリティー面で高いレベルを要求されたり、データが重要であるが故にスピードも重視されてきます。復旧が必要なデータというのは、やはりすぐに必要なものなのですよね。なので、やはり復旧会社を選ぶ基準としては、セキュリティー面やスピード面を重視されているようです。実際には、状態を悪化させないような技術面というのも必要なんですが、お客様にはその認識はまだ薄いかも知れないですね。
G:
「データの悪化」ということですが、前回も「時間が経てば経つほど状況が悪化してしまう」という話を聞きました。それは物理障害に限らず論理障害でも時間が経つことで悪化するものなのでしょうか。
西原:
単純な時間の経過だけで悪化することはないと思いますが、電源のON、OFFで悪化することはあります。あとは、ファイルを修復するコマンドを打ったりしてしまうと、16進数の並びが変わってしまいます。先ほどもRAIDを入れ替えた例をお話しましたが、やはり人の手が加わってしまうと人的ミスが起こりますので、症状が悪化する可能性が高いですね。
Linux系ですとファイルシステムを修復するコマンドというのがあらかじめ用意されている場合があります。Windowsでいうところのチェックディスクみたいなものですね。あれで直ることもあるんですけれど、壊れたデータが戻ってくることはほとんどなくて、壊れたデータは壊れたデータで別のところに隔離されて、誰からもアクセスできない状態で保管されてしまうこともあります。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/P1420270_m.jpg)
G:
何かファイルが壊れてしまって、それをどうしても使いたいから復旧させるコマンドを使ってみたというのは、そもそも間違いであるということですね。そういう用途ではないと。
西原:
そうですね。そういう用途ではないです。
G:
ちなみにそうした操作を行ってしまったことによって、実際に業者に依頼した場合も復旧が遅れてしまったり、困難になってしまうことがあるということですか?
西原:
そうですね。非常に困難な場合があります。あとはデフラグもですね。
G:
デフラグしてはいけないのですか?
西原:
Windowsではデフラグが結構ビジュアライズ化されていて、「データが移動しますよ」というイメージが表示されますが、あれがまさに問題でして、壊れている状態で持ってきていただければ、「おそらく元の状態はこういう構成だろう」というのが分かるのですが、壊れた状態でデフラグを掛けられると、壊れたデータがどんどん入れ替えられるので、ぐちゃぐちゃになって分からなくなってしまうのですよ。あれは厳しいですね。
G:
先ほどのRAID入れ替えの例と同じですね。
西原:
そうです。
G:
手を加えないということ以外にも何か対策はありますか?
西原:
そもそも壊れにくい環境にしておくということが大事です。夏場ですとやはり、熱によるPCBの物理的な基板の故障とかですね。基板がショートして焦げるということもあります。
G:
焦げるのですか?
西原:
夏場は非常に高温になっているので、そのせいでチップ等が劣化すると考えます。僕らのような復旧チームは結構やけどをするんですよ。いくら社内の空調が良くても、サーバーの端っこのほうは空気の流れが悪くて熱くなっていたりということもあるので、なるべく換気のいいところに置いたりする必要があります。個人のユーザーでも、HDDをタワー型パソコンに詰める時になるべくギチギチに詰めるのではなくて、余裕を持って詰めたりとか、やれることはたくさんあります。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/P1420285_m.jpg)
G:
最も多い物理的な故障事例はどんなものでしょうか?
西原:
一番多いのは外的な衝撃だと思います。例えば外付けのHDD等を落としてしまうことですね。あと、熱による故障だと確証があって送られてくるわけではないので、統計データは無いのですが、「熱がトラブルの原因になる」ということがHDD業界では常識とも言われるくらい多いです。
G:
つまり落ちないようにしておくことや、過剰な熱が出ないように換気を良くしておくことで、かなりの部分が防げるということでしょうか。言い換えると冗長化しておくことも大事だけれど、サーバーの扱いにまず気をつける必要があるということですね。
西原:
人の手でなんとかできる部分を、まずなんとかしないといけませんね。
G:
データを復旧するという観点から、ファイル構成の上でこうしておくといいよ、ということはありますか?
西原:
売っている外付けはほとんどFATで売られているんですけれど、あれはFATのままでは使わない方がいいですね。Windowsだけで使うのであれば、一回NTFSにフォーマットし直して使った方が、非常に復旧しやすいですね。パーティーションも細かく区切った方がこれも非常に復旧しやすいです。
復旧しやすいというのは、データの復旧できる量も増えて、精度も高くなるということです。壊れた時もそのパーティションだけで済みますし、基本的にWindowsは4つまでパーティションを区切ることができるので、4つに区切っておけば、1つが死んでも残りの3つは生きてたりするんですけれど、全く区切っていないと全部が死んでしまいます。
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/P1420249_m.jpg)
G:
パーティションを多く区切ることによって、復旧がしやすくなったり、復旧の精度が高くなるということは、問題の部分が特定しやすくなるということですか?
西原:
管理情報が広範囲に点在しなくなるので復旧の観点から見るとやりやすいですね。
G:
復旧の時に一番重要なのは、どこにどの情報があるのかを探しやすくしておくということですね。そういう意味でパーティションも多く区切っておいた方が壊れた時に特定しやすいと。
西原:
例えばパーティションを区切らずに使っている場合は、HDD内の1億セクタのどこかに情報があるという状況です。それを2個に区切っておくことで、半分の5000万セクタの中のどこかになります。単純に探す量も減るということですね。
G:
ちなみに初めてZFSを復旧するにあたって、どれくらいの時間がかかりましたか?
西原:
2週間~3週間くらいですね。
G:
試行錯誤しつつも、3週間で直すことができたということですか?
西原:
「たった3週間で」と外部の方は思うかもしれませんが、社内では「まだ直らないのか!」という感じです。私たちは1秒もはやく1つでも多くのデータを復旧することを使命として掲げています。お客様からの要望もありますが、とにかくスピードは重視していますので。通常のRAIDであれば、復旧自体は1日が当たり前という感じですね。ただ、あまりに容量が大きい場合は、中身のデータを移すのにお時間をいただくこともあります。その場合でも、早急に必要なデータだけをUSBの外付けHDDなどに移して、そこだけすぐにお渡しすることもできます。
G:
データを移すのに時間が掛かるということは、データはいったんどこかに吸い出されて、そこで直すという感じですか?
西原:
吸い出しはせず、専用復旧設備上でRAIDを組まれた状態で置いてあるという感じですね。
G:
HDD24台という大きな規模のものでも、通常のファイルシステムで大きな問題が無ければ、1日で必要なデータを受け取ることができる可能性があるということですね。
西原:
はい。
G:
これ以上の規模では少し厳しいというものはありますか?
西原:
いや、ないですね。既存のファイルシステムで、弊社で解析が終わっているものに関しては、どんなにディスクが増えてもそれほど問題はありません。私たちは1秒でもはやく1つでも多くのデータを復旧して納品するために365日真剣に仕事をしていますので、そういったことの為に日々の技術研究を欠かすことはありません。
G:
ありがとうございました。
データ復旧|PC・サーバー・RAID機器のHDD復旧ならデータ復旧.com
![](https://i.gzn.jp/img/2011/07/22/jdt_zfs_repair/Snap684.jpg)
・関連コンテンツ
in 取材, インタビュー, ハードウェア, 広告, Posted by darkhorse_log
You can read the machine translated English article What is the research team of "Japan Data….