広告

「RAID/サーバー復旧の職人」が考える、データ復旧率95.2%を支える技術の源とは?



2019年はHDDのデータに関する話題が多かった1年でしたが、IT化が進みゆく社会にデータトラブルはつきものです。特に年末年始のような長期休暇明けには、企業のサーバートラブルが頻発するといいます。NTFSext4といったファイルシステムが破損していたり、RAIDの不具合やブートセクタ不良など、「なにか直接手を加えたわけではないが、データにアクセスできなくなっている」という事例は数多く存在します。そうした数多くのストレージ障害にも対応できる「RAID/サーバー復旧の職人」が、「データ復旧率95.2%」と「11年連続データ復旧サービスにおける国内売上ナンバーワン」の実績を持つ、デジタルデータソリューション提供のデータ復旧サービス「デジタルデータリカバリー」で日々復旧作業にあたっていると聞きつけたので、RAID/サーバーの複雑な障害にどう立ち向い、なぜ高い復旧率を実現できるのかを、実際の事例をもとに「職人」本人にお話してもらいました。

データ復旧.com【デジタルデータリカバリー】|復旧率95.2%のデータ復旧サービス
https://www.ino-inc.com/


左が「RAID/サーバー復旧の職人」こと、デジタルデータリカバリーでロジカルチームのチーム長を務める柳田悟さん、右がエンジニア経験もあるというマーケティンググループの嘉藤哲平さんです。


GIGAZINE(以下、G):
本日はよろしくお願いします。さっそく今回はRAID/サーバーの障害についてお伺いしたいのですが。

マーケティンググループ 嘉藤哲平(以下、嘉藤):
それでは企業の共有サーバーがオフィス移転後に起動しなくなってしまった、という事例なんてどうでしょうか。

G:
オフィス移転の際にサーバーが起動しなくなるということは結構多いのでしょうか?

ロジカルチームチーム長 柳田悟(以下、柳田):
結構多いです。今回は移転の際に何かのはずみで筐体が壊れて、それがもとでHDDが物理的もしくは論理的に壊れてしまったということが考えられます。単純に外付けされたHDDの場合はサーバーから取り出して少し修復すればデータが見えることが多いのですが、RAIDが組まれている場合はなかなかそうもいきません。RAIDの場合はHDDを取り出して1本ずつ見るというのは障害をさらに悪化させかねない行為なので。


G:
RAIDを組んだデータ全体がだめになってしまうと。

柳田:
その通りです。この事例は弊社でも何度か復旧実績がある型番のサーバーで、総容量が50TB以上にもなる比較的大規模なものでした。社内のデータを保管する共有サーバーとして利用していたそうです。

嘉藤:
お客様がIT系の企業様だったので、先方のサーバー担当者様もデータに関する知識をある程度お持ちではあったのですが、復旧方法は全く検討がつかないということで弊社に依頼をいただきました。今回の事例は弊社のトップクラスエンジニアをもってしても少々手こずった難易度の高い障害でしたね。


G:
実際に復旧を担当した柳田さんも難しい案件だと感じましたか?

柳田:
そうですね、今回は自分を中心とした3人のチームでやらせていただいたのですが、他の2人にもいろいろ協力してもらって分析を進めてやっと復旧できた、という感じですね。

G:
今回は筐体不良およびファイルシステム異常ということですが、これは筐体不良がファイルシステム異常を引き起こしたということでしょうか?

柳田:
バイナリ上から見るに、筐体がまず壊れて、それが発端となってディスクへの書き込み時に異常を引き起こしたとみています。

G:
この場合の筐体不良というのはぶつけてなにか起きたとか、そういうことでしょうか?

柳田:
おそらく。ぶつけたとか移動時の扱いがよくなかったとか、そういった原因である可能性が高いです。

G:
オフィス移転となるとどうしてもサーバーの物理的な運搬が伴いますし、サーバーを移動させるということ自体がリスクですもんね。移動がなくとも筐体不良は起こり得るものなのでしょうか?。

柳田:
そうですね、経年劣化などで筐体不良となるパターンも多いです。

G:
それで移転が終わって起動しようと思ったら、しなかったと。現場に行って最初にサーバーの症状を見たときはどういう感じだったのですか?

柳田:
まず一番はじめにディスク構成を分析しました。ディスクに関しては全部で30本ほどあって、OS領域とストレージ領域が分かれていることを前提に、データ環境が再構築できるかをいろいろ分析して試したという感じですね。論理的な不良が発生していたので、最初の故障診断の段階では壊れたデータが具体的に見えるというところまではこぎつけられなくて。OS領域があるサーバーに異常は見られなかったのですが、もう片方のデータ専用サーバーのファイルシステムが壊れているという状態だったんですね。


OS部分は独立した領域にRAID1が組まれていてそこは問題ないと。OS領域のHDDが入っているサーバーのデータ領域も生きている。じゃあ生きている部分のデータだけ出せるじゃないかと思われるかもしれませんが、実際の構成は2つのサーバーのデータ領域が独立してなくてですね。

G:
OSが入っている2本はRAID1でミラーリングされていて、それとは別にサーバーのデータ領域部分がつながっていたと。

柳田:
分析を進める段階で少しずつ判明したのですが、構成はサーバー1のデータ用HDD複数本とサーバー2のHDD複数本でそれぞれRAID6が組まれていました。ただサーバー2のほうについてはさらに複雑で、いきなりデータ領域が1つのサーバー内で分断されていた状態でして、データ領域としては合計3つのRAID6が存在していました。それで、最終的にはその3つのRAID6がJBODで束ねられていたんですよ。だからちょっと複雑で。はじめはサーバー1とサーバー2の領域が独立しているものと思っていたので、作業がなかなか進みませんでした。最終的にサーバー2はRAID6を組んだ中でいきなり領域をズバッと切っているということがわかって。


G:
なかなか複雑なデータ構造だと思うのですが、もともとお客様から事前に情報はあったのでしょうか?

柳田:
なんとなくはありました。どこにどうディスクを追加したかなど、サーバー管理者ならわかる情報は伝えていただきましたけど、例えばRAID6が両方組まれているとか、どの領域でデータが分断しているかなどはもちろんわからない状態なので、そのあたりは見ていかないとわからないところになりますね。

G:
見ていくというのはどうやって見ていくのでしょうか?

柳田:
バイナリを分析して見ていきます。複数のディスクで組まれたRAIDも単体のディスクも最終的には1つのボリュームとして見ることができるので、そうやって見たときに整合性がとれているかを確認していきます。


G:
このバイナリのパターンだったらJBODだとかRAID6だとか、そういう感じでしょうか?

柳田:
そういったイメージです。バイナリファイルでこの文字列のあとはこの文字列が来るはずであるのに来ていないからおかしい、といった判断をしています。

G:
そういった判断はいままでの積み重ねがものをいいそうですね。

柳田:
そうですね、マニュアルのようなもので解決できる問題ではないので。

嘉藤:
弊社としても、仕組みで直せるものはきちんと仕組みを確立して復旧できた方がいいんです。それができる場合もあるのですが、今回の事例のように構成が複雑な場合は経験の浅いエンジニアには難しいです。大型のRAID/サーバーや重度障害の案件は、直接トップクラスのエンジニアが復旧作業にあたるパターンが多いです。


G:
それで原因がわかって修復作業に入っていくと思うのですが、分析用の専用設備みたいなものはあるのですか?

柳田:
バイナリを分析したり書き換えたりするツールを複数用意していて、それを用いて分析、修復する作業を複数回繰り返しました。

G:
分析して修復する作業を複数回繰り返す、というのはどういうことなのでしょうか?一回ぱっと見て原因がわかって、ここを置き換えて「はい終わり!」じゃなくて、漆を塗るみたいな感じで、複数回繰り返すということなのでしょうか?

柳田:
今回の場合は一発で原因がわかったわけではなくて、分析に分析を重ねてやっとわかったという感じでした。分析して、その結果をもとにデータを再構築するのですが、はじめに想定していた構造と違った部分があったので、もう一回分析して、追加で修復してという感じで。いろんなパターンを試して、再構築をかけていきました。

G:
いっぺんにファイルシステムのどこが壊れているかがわかるわけではなく、直していくなかでここも壊れている、ここも壊れているというのを後追いでどんどん直していくと。

柳田:
破損が少ないものとか、RAIDの構成が単純であれば、わざわざ繰り返す必要はありません。ノウハウとして共有されているものなので、試行錯誤もなく一発で再構築できますね。

G:
今回の事例はパーティション方式がMBRということで、他にもパーティション方式としてGPTがありますが、そういったシステムの違いによって復旧の難易度は変わるのでしょうか?

柳田:
修復の難易度としては、個人的にはGPTのほうが直しやすいと感じます。データがないとか、崩れてしまっている場合に、別の場所のバックアップデータを参考に修復をかけるのですが、GPTの場合はそのバックアップデータが比較的多くて、いろいろなところからデータを取ってきて修復をかけられるので、私の意見としてはやりやすいですね。


G:
GPTのほうが新しいからこそ、バックアップシステムもパワーアップしてるのですね。

柳田:
そうですね。MBRにあってGPTにないものはほとんどないので。バックアップの面だとか、容量だとか、作成可能なパーティションの数だとか、基本的にはGPTのほうが性能としては高いものだと感じます。

G:
今回の事例はお客様に納品するまでどれくらい時間がかかったのでしょうか?

柳田:
だいたい1カ月かかっていないくらいですね。

G:
1カ月というのは、復旧作業の中では短い方なのか、時間がかかった方なのかどちらなのですか?

柳田:
かなり時間を要した部類です。弊社でお受けする依頼の8割程度は2日以内に復旧できているので。

G:
依頼して2日!?

柳田:
はい、なのでそこから比べるとかなり時間がかかった事例です。

嘉藤:
NASや企業のサーバーであっても、即日、翌日に復旧できるというのも珍しくはないですね。

G:
大抵の事例は、朝に復旧を頼んだら次の日の夕方には復旧できているイメージなのでしょうか?

柳田:
重度の物理障害が発生していると時間がかかる場合がありますけど、一般的なものはそのイメージで復旧が可能です。

嘉藤:
依頼の8割というのはもちろん物理障害の案件も含めた数字で、物理障害が発生していても即日・翌日といった事例はたくさんありますね。


柳田:
この筐体も初期構成の状態であれば私にとってさほど難しくなかったのですが、お客様がどんどん自分でカスタムしたりディスクを追加したりして使われていたので、複雑になっている分時間がかかってしまいました。

G:
難易度でいうと、データ不良の場所がブートセクタである場合と通常の記憶領域である場合では、復旧の難易度は変わるのでしょうか?

柳田:
例えばプラッタにひどいスクラッチがある場合など、ファイルの情報自体が欠損してしまっている場合の復旧は難しいです。論理障害の場合であれば、初期症状はフォルダ構成を司っている部分の破損がほとんどなので大抵は修復可能なのですが、お客様の方でいろいろ試したり使用を続けたことでファイル自体の情報が書き換わってしまうと、スクラッチと同じく復旧の難易度が高くなります。

G:
今回はMFTの欠損があったということで、フォルダがどういう構造になっているかという情報がなかった、という状態ですよね?

柳田:
はい。

G:
事前にどのフォルダの中にどんなファイルが入っているといった情報が全くない中で、どう復元していくのでしょうか?

柳田:
また新しくフォルダを作って復旧したデータを入れてといった作業ではないんです。MFTも情報の集合体なので、欠けてる部分だったりとか、明らかに値が違うものだったりとかを直していく感じですね。その結果としてフォルダができて、名前が入っていくので、フォルダ構造を意識して復旧するというイメージではないです。

G:
バイナリを見て、これは経験上なんか違うな、おかしいな、という部分を数字の羅列を見ながら直していくと、自然とフォルダ構成が復活しているのですね。

柳田:
そうですね、修復されたフォルダ構成を見て問題がないかどうかも同時に確認していきます。それでも構成が崩れている部分があったら、別の部分も見て手直ししていきます。

G:
RAIDの再構築もバイナリを修正するのでしょうか?

柳田:
再構築に関してはバイナリレベルではないですね。バイナリレベルで再構築する場合もありますけど、弊社の専用のツールを使って強制的にRAIDを組む感じですかね。

G:
強制的に?

柳田:
HDDに残っているRAID情報とは無関係に、こちらの指定した通りにRAIDを組ませるんです。もともとのRAID情報から組まなくとも、条件さえ整えていればデータの確認が可能になります。それで再構築に成功する時もあればできない時もあるので、トライアンドエラーを繰り返して検証していきます。

G:
今回の事例のように、法人からの大規模なサーバーの復旧依頼は多いのですか?

柳田:
そうですね。法人のお客様からHDD何十台という規模のサーバーの依頼をいただくことは多いです。


G:
復旧する際は、依頼側がトラブル復旧を事前に試みていない方がやりやすいのでしょうか?

柳田:
すごくやりやすいです。お客様や先に依頼した他社で何をやったか、という情報が全部あればいいですけど、そこはどうしても不透明になりがちなので。あと、先にも話しましたが、症状悪化の可能性を考えるといち早くお問合せいただきたいところです。

嘉藤:
逆に言えば、そこがエンジニアとしての付加価値になるところですね。ただ決まった作業をしていくのではなく、専門知識や経験則を駆使してどんな状態からも直していくというのが、弊社のエンジニアの腕の見せ所ですね。

G:
これだけ難しい依頼を受けていても全体で復旧率95.2%ということですが、復旧率が上がっていくにつれて「この故障も復旧できるだろう」と依頼側が感じて、ものすごく難しい依頼がどんどん増えていって復旧率が下がっていくようにも思えるのですが、それでもこれだけ高い復旧率を維持できている秘けつはあるのでしょうか?

柳田:
プラッタ上のスクラッチだとか、データを削除してもう何年も経過しているとか、上書きしてしまっているとか、いろいろな難しい依頼が来るのですが、基本的に弊社のエンジニアは全員復旧率100%を目指しています。その中で直らなかった案件に関しても、どうやったら直せるか常に研究しているので、技術力が向上していくと。


G:
復旧できなかった残りの5%についても研究分析をバッチリやって次につなげていくということですね。

嘉藤:
データ復旧のエンジニアは経験値がものをいう「職人」みたいな側面が大きいです。弊社が承った累積ご相談数は、2019年12月現在はもう20万件を超えていまして、そういった実対応の積み重ねからどんどんエンジニアのノウハウが蓄積されていくのも高い復旧率を実現できている秘けつです。復旧できなかった案件に対しても研究をしますし、海外研修なども定期的に行っています。ロシアや中国、ヨーロッパなどにエンジニアが赴き、海外の技術を導入して「この症状直せるようになりました」といった報告が社内であげられます。そのノウハウも社内で横展開して復旧技術の向上に努めているわけです。

G:
実績ベースでのノウハウだけではなく、外から新しい技術を持ってくると。

嘉藤:
技術開発に関する投資は惜しみませんね。お客様のデータを最も早く、安全に復旧させることが私たちの使命なので。

G:
AppleのAPFSなど比較的新しいファイルシステムも出た瞬間に研究を行うのでしょうか?

柳田:
そうですね、まだファイルシステム自体が途上といった感じですが。

G:
確かにストレージ全体としてはAPFSなどの新しいファイルシステムが使われている割合は少ないように思いますが、それでも案件が来た時のために研究すると。

柳田:
APFSでRAIDが構成されているものはまだ見ていませんが、この先どうなるかわからないですし、依頼もRAIDだけではもちろんないですから。過去の段階では「これは研究しても無理だろう」と思われていた事例も、今は直せるということもあるので。

嘉藤:
業界全体で「無理」とされていた症状であっても、今現在弊社で復旧できるようになっている症状もあるわけです。お客様からの依頼がある以上、診断の段階で難しい症状だと分かっても、その難しさをしっかりと説明したうえで対応させていただいています。

G:
難しいからやらない、ではなくまずはやってみると。

柳田:
はい。難しい症状であっても必ずトライします。それで直った事例もたくさんありますから。

G:
他社だと「そんな症状絶対無理です」とお断りされたのを、デジタルデータリカバリーさんだとまずはやってみて、その部分がノウハウにつながっていくということなんですね。

嘉藤:
例えば、自分の家族が重病を患いお医者さんに治療を頼んだとして、全く手も施されないまま追い返されるなんてたまったものではないですよね。データは代えがきかないその人だけの価値があるものですし、法人様においても会社のデータが消えてしまったら倒産しかねないなんてパターンもあります。そういった大切なものを扱うわけですから、当たり前ですが全力で対応をします。


G:
論理的なだけでなく、熱いハートも持って復旧に取り組んでいらっしゃるんですね。

嘉藤:
柳田の場合はMBRよりGPTのほうが得意という話でしたが、弊社にはいろいろなエンジニアがいて、それぞれに得意な分野があります。ご依頼の機器の症状に合ったエンジニアを担当させているのも95.2%という復旧率に関わっているところだと思います。

G:
エンジニアの多様性を確保していると。

嘉藤:
ロジカル、フィジカル、メモリ、ロジスティクスとエンジニアをチーム分けしているところは弊社以外見かけませんね。海外出身のエンジニアも多く在籍しています。


G:
そうすると会社の規模というのも大事になってきますよね。エンジニアの得意な分野に合わせて案件を割り当てていくとなると、多種多様なエンジニアを取りそろえられるだけの会社の規模も必要だと感じるのですが。

嘉藤:
そういった意味では、弊社はデータ復旧サービスにおいて11年連続国内売上ナンバーワンという実績を持っていますし、対応機器についても制限は設けていません。

G:
機器に制限がないとなると、全く経験のない未知の案件が来るということはないのでしょうか?

柳田:
もちろんありますよ。でも案外なんとかなるものです。電話機や防犯カメラ、カセットテープ、最近だとドローンまで、データが記録されているものは何でも来ますね。


嘉藤:
企業のサーバーなど、物理的に動かせないような大きなサーバーの依頼もありますが、そういった場合は無料で出張・診断するサービスを行っています。柳田は各地を飛び回っているエンジニアなので、愛知や大阪、遠いところだと沖縄や北海道まで行くこともあります。

柳田:
行きますね。日帰りとかもあります。

G:
呼んだらすぐ来てくれる感じですね。

柳田:
すぐに準備して飛んでいきます。法人の場合、データの損失によって仕事が止まってしまうといったことも多いですから、緊急度は高い傾向にあります。現地で実際に診断して、直せるならそこで直してしまいますね。


G:
特に法人のデータだと、TPMなどを用いて暗号化されているケースがあると思うのですが、そういった暗号化のあるなしは復旧の難易度に関わってくるものなのでしょうか?

柳田:
関わりますが、お客様側でIDやパスワードを把握していればそれを入れて確認しますし、大半は事前情報がなくとも復号化して解読できます。

G:
暗号化されているデータは基本的に外部には見られたくないデータですよね。そういったデータを守るセキュリティの観点は昨今、特に法人が気にするところだと思うのですが、そういったセキュリティ対策はどうなのでしょうか?先ほどオフィスを案内していただいた時に、空港のゲートのような金属探知機があって、お聞きする前から厳重なんだろうなとは感じているのですが。

柳田:
作業の前には機密保持を締結させていただくのと、会社の仕組みとして機器や情報を持ち出すことはできないようになっています。

嘉藤:
情報を扱うエンジニアが一番厳しくセキュリティ管理されていますね。エンジニアはみんな同じ作業服に着替えますし、オフィス内には多数の防犯カメラがついています。入り口に金属探知機と警備員による二重のチェックがあるので、お客様の機器の持ち出しや、記録媒体の持ち込みは事実上不可能ですね。


G:
エントランスに「情報漏えい」に関する看板とともに真っ黒な箱が置いてありましたが、あれもセキュリティに関するものなのでしょうか?


嘉藤:
はい、あれはDDHBOXというもので、最新マルウェアの不正通信を検知してブロックしてくれる機器になります。データ復旧以外にもセキュリティ事業などを展開していまして、先日はハッキングに対するセキュリティ技術について、弊社がベトナム政府と技術提携を結んだということがありました。

日本初、ベトナム公安省サイバーセキュリティ&サイバー犯罪捜査局へ技術提供で合意し覚書を締結|デジタルデータソリューション株式会社のプレスリリース
https://prtimes.jp/main/html/rd/p/000000040.000017714.html

G:
国家レベルでセキュリティの事業を展開している会社というと、なんだか安心できますね。お話を聞いていると、「GIGAZINEにもデジタルデータリカバリーさんのエンジニアが1人いて、ずっとサーバーのHDDを守っていてほしい」と思ってしまうのですが、そういった契約制のサービスはないのでしょうか?

嘉藤:
顧問契約みたいなものはありませんが、HDD本体にデータ復旧を無料で行う保証をつける「デジタルデータワランティー」というサービスはあるので、疑似的に弊社のエンジニアがHDDを守ってくれる状態にすることはできますね。ただ筐体が壊れただけならメーカーに依頼すればなんとかなることもあるのですが、弊社に依頼が来る事例はHDD自体だとか、HDDの中のファイルシステムだとかに異常が発生しているケースがほとんどです。筐体そのものに付帯しているメーカー保証に比べて、HDD自体のトラブルに対する保証サービスは認知度が低いと考えています。サーバーが故障した場合、皆さん基本的にメーカーに問い合わせるわけですが、メーカー修理だと筐体は直っても肝心のデータは消えてしまうということもあります。この保証サービスは、データをきちんとお守りするという点を重要視しています。

Digitaldata-warranty|データ復旧保証サービス
https://www.digitaldata-warranty.com/


G:
その保証を使えば、メーカー保証では対応が難しいトラブルも無料で対応していただけると。

嘉藤:
通常のデータ復旧で弊社に依頼いただいたお客様に利用いただくケースなんかは多いです。一度データの消失を経験されている分リスクは理解されていますし、料金面においても安価なので。

G:
保証がついていれば今後も安心できますね。

嘉藤:
最近は復旧ツールなどがネット上に広まっていますが、それを使って直るレベルの故障ではない場合が多いです。変にツールを利用してしまうと、知らず知らずのうちに症状が悪化してしまったり、最悪復旧できなくなってしまったりすることもあります。HDDの復旧は最初の業者選びがとても大切なんですよ。

G:
ぱっと見て「あ、これツール使ってるな」とわかるのでしょうか?

柳田:
わかりますね。ツールを使った痕跡があることもありますし、ツールのプログラムデータやログそのものの痕跡が残っていることもあります。

G:
「下手にソフトを使わず、最初に言ってくれれば……」という感じなのですね。

柳田:
絶対取り出したいデータであれば、自分でいろいろいじってしまう前にお持ちいただいた方が最終的に完全な形でデータをお渡しできる可能性が高くなりますので、最初にご相談いただくのがお客様にとっても良い形だと思います。

G:
サーバーのデータ容量はどんどん増えてきていると思いますが、「この容量までなら大丈夫」というラインはあるのでしょうか?

柳田:
大容量のものだとRAID構成が複雑であったり、特殊な筐体であったりすることが多いため、容量と復旧難易度は相関関係にはあるかもしれませんが、容量が直接難易度に関わることはありませんね。


G:
容量は難易度に関係ないとなると、ファイルシステムの種類は難易度に関わってくるのでしょうか?

柳田:
それは関わります。今回お話した事例はNTFSという一般的なファイルシステムなので、ファイルシステムだけ見ると難易度としては高くはありません。他にもHFS+FATとかは直しやすいですね。Linux系でもext4とかXFSとかは、NTFSに比べると直しづらくはありますが、それでも直しやすい分類ではあります。それ以外のAPFSとかZFSなどは多少厄介な部分もあります。

G:
それは新しいファイルシステムだからでしょうか?

柳田:
大きくはノウハウの量が関係していますね。一般的なファイルシステムであれば膨大な過去実績があるので復旧もしやすいです。

G:
ファイルシステムの構造的に難しいというよりかは、まだ誰もやったことがないから難しいと。

柳田:
そういうことです。ただ、それぞれのファイルシステムに共通点もあったりするので、新しいから直せないということはないですね。

G:
ということは、新しいファイルシステムもこれからどんどんノウハウがたまるので、この先ずっと復旧が難しいファイルシステムというものはないということなのでしょうか?

柳田:
それはそうなんですが、ファイルシステム間の復旧難易度の力関係はずっと変わらないと考えています。今でも復旧が簡単なNTFSについてもこれからどんどんわかることが増えて、さらに直しやすくなっていくこともありえます。新しいファイルシステムが研究されるのと同じように古いファイルシステムも研究されていくので、ZFSとかAPFSは相対的に難易度の高いファイルシステムであり続けると思いますね。

G:
最近だとHAMRなど、データ書き込みをアシストしてくれる機能をつけて大容量化を目指したHDDがありますが、そういうHDDは論理的に従来のHDDと差はあるのですか?

柳田:
論理面の違いはないですね。そういったディスクは弊社のフィジカルチームがHDDの内部環境や部品構造、ファームウェアの研究を進めているところです。


G:
仮にHAMRなどの機能を搭載したHDDでも、論理面の障害であれば今までと同じように直せると。

柳田:
その通りです。

G:
最後の質問になりますが、復旧のしやすさと利便性を考えたオススメのストレージ構成は何でしょうか?

柳田:
やっぱりRAID6じゃないですかね。直す分にも難易度としてやさしい方ではありますし、2台分の容量をパリティとして使ってしまいますが、利便性の面でもRAID1で全てミラーリングしてしまうよりかははるかに効率がいいです。RAID6は2台のHDDがなくても復旧できるので、データ保存の安全性という観点からも優れた構成ですね。


G:
なるほど。本日はありがとうございました。

データ復旧.com【デジタルデータリカバリー】|復旧率95.2%のデータ復旧サービス
https://www.ino-inc.com/

この記事のタイトルとURLをコピーする

in 取材,   インタビュー,   ソフトウェア,   ハードウェア,   広告, Posted by log1n_yi

You can read the machine translated English article here.