RAIDとは？更改時に知るべき種類・選び方と「バックアップではない」理由

RAID を組んでいるのに困る、という現場の状況

サーバーやファイルサーバーの更改を検討していると、「RAID を組んでいるのに、なぜバックアップの話が繰り返し出てくるのか」と感じる場面があります。RAID があれば安心だと聞いていたのに、障害時の説明を受けると急に不安になる、という担当者は少なくありません。

背景には、ディスクの大容量化やワークロードの変化があります。同じ構成を惰性で踏襲すると、リビルド時のリスクや保守切れに気づかないまま更改してしまうことがあります。加えて、ランサムウェア対策の観点からも「RAID とバックアップは別物」という理解が改めて問われています。

本記事では、RAID の役割と主な種類、障害時に実際に何が起きるか、バックアップとの違い、そして更改時に構成をどう選び直すかを整理します。読み終えたときに、自社が「何の障害から守りたいのか」を切り分け、次の判断に進める状態を目指します。

RAID を組んでいるのに困る、という現場の状況

まず要点です。RAID を導入していても不安が残るのは、RAID が守る範囲と、担当者が守りたい範囲がずれているためです。

現場では、こうした状況が起こりやすいものです。「冗長構成だから大丈夫」と引き継いだサーバーで、ある日ファイルが誤って削除される。あるいは、ランサムウェアで共有フォルダーが暗号化される。RAID は正常に動いているのに、失われたデータは戻らない。ここで初めて、RAID が何を守る仕組みなのかを正確に知らなかったことに気づきます。

判断ポイントは、いま自社で守れているのが「何の障害」なのかを切り分けることです。ディスクが 1 台壊れても止まらないことと、消えたデータを元に戻せることは、まったく別の話です。

注意したいのは、この混同が更改の先送りにもつながる点です。「RAID があるから止まらない」という思い込みは、保守切れや性能不足の見過ごしを招きます。次章から、役割を順番に整理していきます。

RAID の役割とは｜何を守り、何を守らないのか

要点として、RAID (Redundant Array of Independent Disks) は複数のディスクを 1 つにまとめ、ディスク単体の故障でシステムを止めないための「可用性」の仕組みです。

RAID の目的は、ハードウェアであるディスクが故障しても業務を継続できるようにすることにあります。ディスクは消耗品であり、いつかは壊れます。その 1 台の故障が即停止につながらないよう、データを複数のディスクに分散したり複製したりして冗長性を持たせます。

判断ポイントは、RAID が守るのは「ディスク単体の物理故障による停止」だという線引きです。ここに含まれないものがあります。人による誤削除、アプリケーションの不具合による論理破損、ランサムウェアによる暗号化。これらは、RAID から見れば「正しい書き込み」として全ディスクへ反映されるため、冗長化しても防げません。

注意点として、「冗長性がある＝データが安全」ではありません。RAID は可用性を高める仕組みであり、データ保護そのものとは目的が異なります。この区別が、後半のバックアップとの違いを理解する土台になります。

RAID の主な種類と特徴｜冗長性・性能・容量効率で比較

要点は、RAID レベルによって「耐えられる故障台数」「容量効率」「性能」が変わり、万能の構成はないということです。

代表的なレベルの特徴を整理します。

向いているケースと向いていないケースも押さえておきます。RAID 5 は容量効率と冗長性のバランスがよく一般的ですが、ディスクが大容量になるほどリビルド時間が延び、その最中に別のディスクが故障する二重故障のリスクが相対的に高まります。可用性を重視する更改では RAID 6 や RAID 10 が選択肢に上がる場合があります。一方、テスト環境やキャッシュ用途など、消えても再生成できるデータには RAID 0 が適する場面もあります。

注意点は、レベルの理論値だけで決めないことです。同じ RAID 5 でも、ディスク容量・本数・コントローラー性能によって実運用の安全性は変わります。用途と復旧要件を起点に選ぶことが望まれます。

障害時に本当に何が起きるか｜リビルド・二重故障・コントローラー故障

要点として、RAID の真価は平常時ではなく障害時に問われます。ここを理解しておかないと、「壊れたら自動で元通り」という誤解が残ります。

ディスクが 1 台故障すると、冗長構成なら業務は継続できますが、内部では「リビルド (再構築)」という復旧処理が始まります。交換したディスクへデータを書き戻す処理で、容量が大きいほど時間がかかり、その間はディスクへ高い負荷がかかります。現場では、このリビルド中に別のディスクが力尽きる二重故障が起きると、構成によってはデータを失うことになります。

判断ポイントは、次の 3 点を事前に確認しておくことです。

• リビルドにかかるおおよその時間と、その間の性能低下を許容できるか。

• 故障時に自動で切り替わるホットスペア (予備ディスク) を用意するか。

• RAID を制御するコントローラー自体が単一障害点になっていないか。コントローラーが壊れると、ディスクが無事でも読み書きできなくなる場合がある。

注意点として、「RAID があるから止まらない」という前提は、保守部材の在庫や交換対応の速さがあって初めて成り立ちます。保守切れの機器では、故障ディスクの交換すら滞ることがあります。障害時の挙動まで含めて、はじめて可用性が担保されると考えるのが実務的です。

RAID とバックアップの違い｜混同すると復旧できない

要点は、RAID は「止めない仕組み」、バックアップは「戻す仕組み」であり、目的がまったく異なるということです。

両者の違いを整理します。

ここが混同されやすい最大のポイントです。RAID は書き込みを即座に全ディスクへ反映するため、「間違った操作」も忠実に反映されます。ランサムウェアによる暗号化や誤削除は、RAID から見れば正しい書き込みであり、冗長化されたすべてのディスクに同じ結果が残ります。過去の状態に戻せるのはバックアップだけです。

判断ポイントは、RAID とバックアップ、さらにアーカイブを、それぞれ目的の異なる別レイヤーとして設計することです。「RAID があるから安心」と言われた構成ほど、バックアップの世代管理や復旧テストが手薄になっていることがあります。保存の分散という観点では、3-2-1 の考え方 (データを 3 つ持ち、2 種類の媒体に、1 つは別拠点へ) が基本になります。

注意点として、バックアップは「取っていること」ではなく「戻せること」が目的です。復旧できるかは、実際にテストしてみないと分かりません。保存目的や期間による整理は、バックアップとアーカイブの違いを扱う記事や 3-2-1 の解説とあわせて確認することをおすすめします。

321ルールとは？バックアップの基本から実装手順、最新動向まで解説

更改時の RAID 選定｜構成をそのまま踏襲してよいか

要点は、サーバー更改は RAID 構成を見直す好機であり、現行構成の惰性踏襲は避けたい、ということです。

更改の現場では、「前と同じ構成で」と依頼されることがよくあります。しかし、前回の構築から数年が経つと、扱うデータ量もワークロードも変わっています。ディスクは大容量化し、同じ RAID 5 でもリビルドの前提が変わっている場合があります。

判断ポイントを、更改時の選定チェックとして整理します。

• ワークロードの変化: 読み書きの比率やデータ量は前回と変わっていないか。

• 冗長度の再検討: 二重故障リスクを踏まえ、RAID 6 やホットスペアの追加が必要か。

• 容量と本数の再見積もり: 将来の増加を見込んだ容量設計になっているか。

• 保守と EOSL: 選定する機器の保守期間と、保守切れのタイミングを把握しているか。

• 復旧設計との整合: RAID だけでなく、バックアップと復旧テストまで含めた全体設計になっているか。

向いている進め方は、要件が固まりきらない場合に、検証環境で構成や性能を確かめてから本番へ移すやり方です。逆に、旧構成をそのまま流用し、性能・保守条件の確認を省くと、更改後に性能不足や保守切れが表面化しやすくなります。

注意点として、RAID 構成の最適解は環境によって異なります。カタログ上の理論値ではなく、自社の用途・復旧要件・保守条件に照らして選ぶことが望まれます。判断が難しい場合は、構成確認や検証を通じて絞り込む選択肢もあります。

RAID 選定チェックリスト（サンプル）

サンプルとして、当社のプリセールスが作成した「RAID 選定チェックリスト」のサンプルを掲載いたします。
あくまでサンプルですので、全ての案件に合致するとは限りませんが、RAID選定を行う際の参考となれば幸いです。

よくある質問 (FAQ)

Q1. RAID を組んでいれば、バックアップは不要ですか。

別物として両方が必要になる場合が一般的です。RAID はディスク故障による停止を防ぎますが、誤削除・論理破損・ランサムウェアによるデータ損失は防げません。過去の状態に戻せるのはバックアップです。目的が異なるため、片方で代替はできないと考えられます。

Q2. 更改時は、これまでと同じ RAID レベルを選べばよいですか。

環境によって異なります。ディスクの大容量化やワークロードの変化により、同じレベルでもリビルドの前提が変わっている場合があります。冗長度・容量・保守期間を再確認し、必要なら見直すことが望まれます。判断が難しい場合は検証環境での確認も有効です。

Q3. コストを抑えたい場合、どの RAID を選ぶべきですか。

用途と復旧要件によります。容量効率と冗長性のバランスでは RAID 5 が選ばれやすい一方、可用性を重視する場合は RAID 6 や RAID 10、ホットスペアの追加が選択肢になります。安価さだけで冗長性のない構成を選ぶと、障害時の損失が大きくなる点に注意が必要です。

Q4. リビルド中に別のディスクが壊れたらどうなりますか。

構成によってはデータを失う可能性があります。特に大容量ディスクの RAID 5 は、リビルド時間が長くなり二重故障のリスクが相対的に高まります。RAID 6 やホットスペアの活用、そしてバックアップの併用で備えることが望まれます。

まとめ

最後に要点を再掲します。RAID はディスク故障からシステムを止めないための可用性の仕組みであり、消えたデータを戻す仕組みではありません。守りたいのが「停止の回避」なのか「データの復旧」なのかを切り分けることが、すべての判断の出発点になります。

更改では、現行構成をそのまま引き継ぐのではなく、ワークロードの変化・リビルドリスク・保守期間・復旧設計まで含めて見直すことが望まれます。RAID 単体で全リスクは吸収できないため、バックアップと運用体制とセットで考える姿勢が実務的です。

• RAID は「止めない (可用性)」ための仕組みで、「戻す (データ保護)」バックアップとは目的が異なります。

• 守れるのはディスク単体の物理故障であり、誤削除・ランサムウェアは対象外です。

• 主要レベル (0/1/5/6/10) は冗長性・容量効率・性能のトレードオフで選びます。

• 障害時はリビルド負荷・二重故障・コントローラー故障まで想定が必要です。

• 更改では現行構成の惰性踏襲を避け、復旧設計まで含めて見直すことが望まれます。

RAID の選定は、用途・復旧要件・保守条件によって適した構成が変わります。現行構成をそのまま踏襲してよいのか、更改を機にどこまで見直すべきか、自社だけでは判断しきれない場面もあります。

横河レンタ・リースは、IT 機器のレンタル・販売に加え、サーバーやストレージの構成設計から更改、運用保守までを組み合わせて提供しています。既存環境や運用方針を踏まえたうえで、RAID 構成や更改後の全体設計を一緒に整理することが可能です。

本記事で紹介した選定チェックリストや RAID レベル比較表、構成例の資料もご用意しています。まずは現状整理の材料としてご活用いただき、構成の確認や検証方法について判断が難しい部分があれば、お気軽にご相談ください。

お問い合わせ (総合) | 法人向けパソコン (パソコン) ・計測器レンタルなら横河レンタ・リース