公開2026.07.11更新2026.09.05 インフラ・クラウド

RAIDとは？RAID0/1/5/6/10の違いと構成・企業のディスク冗長化設計を実装目線で解説【2026年版】

RAID（レイド）とは、複数のディスクを1つにまとめて、耐障害性や読み書き速度を高める仕組みです。この記事では、ストライピング・ミラーリング・パリティという3つの原理から、RAID0/1/5/6/10それぞれの構成と違い、最小台数・容量効率・何台まで故障に耐えるかを比較表で整理します。構築と復旧の手順は、Linuxのmdadmとファイルシステム側のZFSで、そのまま打てるコマンドとして示しました。さらに、ディスクが1台壊れたあとのリビルド（再構築）でなぜ二次故障が起きるのか、ホットスペアやRAIDコントローラは何をするのか、RAID5の「ライトホール」とは何かまで、インフラ実装の目線で踏み込みます。そのうえで、用途別にどのRAIDレベルを選ぶか、そして「RAIDがあればバックアップは不要」という誤解に、条件付きで答えを出すのが本記事の狙いです。

まとめ｜RAIDレベルの選び方とバックアップとの役割分担の結論

RAIDは、複数の物理ディスクを束ねて論理的な1台のディスクに見せる技術で、目的は大きく2つ、速度を上げることと、1台が壊れてもデータを失わない冗長性を持たせることです。この2つをどう配分するかがRAIDレベルの違いになります。速度だけを取り冗長性を捨てたのがRAID0、まるごと複製して壊れに強くしたのがRAID1、容量効率と耐障害性を両立させたのがRAID5とRAID6、速度と信頼性を高次で両立するのがRAID10です。まず結論を数字で押さえると設計がぶれません。

実務での選び方はおおむね決まっています。データベースのように書き込みが多く止められないシステムはRAID10、容量効率を重視するファイルサーバーやバックアップ保管先はRAID6、速度が命でデータが消えても作り直せる一時領域だけがRAID0、という配分が基本の型です。ディスクが大容量化した現在、RAID5を大型ドライブで組むのはリビルド中の二次故障リスクが高く、避けるべき場面が増えました。クラウドではさらに前提が変わり、AWSは自社のブロックストレージ上でRAID5/6を推奨していません。そしてもう1つの結論は明快で、RAIDはバックアップの代わりにはなりません。RAIDが守るのは「ディスクの物理故障」だけで、誤削除・ランサムウェア・筐体ごとの災害には無力です。ディスク冗長化としてのRAIDと、別媒体・別拠点へ退避するバックアップは、目的が違う別々の備えとして両方を持つのが堅実な設計になります。

RAIDとは｜複数ディスクを束ねて冗長性と速度を得るストレージ技術

RAIDは「Redundant Arrays of Inexpensive Disks（安価なディスクの冗長配列）」の頭文字で、1980年代後半にUC Berkeleyの研究で体系化された分類が基礎になっています。まず、なぜ複数ディスクを束ねるのか、その3つの基本原理と、実装の土台となるコントローラの種類を押さえます。

RAIDの定義とストライピング・ミラーリング・パリティの3原理

RAIDは、複数のディスクを組み合わせて1つのボリューム（アレイ）として扱う技術です。単体ディスクは、容量・速度・壊れやすさのすべてを1台に依存します。ディスクが1台壊れれば、中のデータは二度と戻りません。RAIDはこの弱点を、複数台に役割を分けることで補います。仕組みの土台は3つの原理です。ストライピングは、データを一定サイズのブロックに分けて複数ディスクへ並列に書き、読み書きを高速化します。ミラーリングは、同じデータを2台以上へ同時に書き、片方が壊れても継続できるようにします。パリティは、元データから計算した誤り訂正用の符号（パリティ）を持ち、故障したディスクの中身をこの符号と残りのデータから復元できるようにする仕組みです。各RAIDレベルは、この3原理をどう組み合わせるかの違いにすぎません。RAIDが担うのはディスクという1つの層の冗長化で、システム全体を止めない設計思想は冗長化の種類と構成、企業の設計判断の解説にまとめており、RAIDはそのうちストレージ層を受け持つ手段という位置づけです。

ハードウェアRAIDとソフトウェアRAID（mdadm/ZFS）の違いと選び分け

RAIDを制御する方式は、専用ハードウェアに任せるか、OSのソフトウェアで組むかに分かれます。ハードウェアRAIDは、RAIDコントローラという専用の拡張カードやサーバー内蔵チップがパリティ計算や書き込み制御を肩代わりする方式です。CPUに負荷をかけず処理が速い一方、コントローラ自体が故障するとアレイごと読めなくなる場合があり、同型の交換部品を確保しておく必要があります。ソフトウェアRAIDは、OSの機能でRAIDを構成する方式で、Linuxのmdadm、ZFSのRAID-Z、WindowsのStorage Spacesなどが代表です。専用ハードが要らず安価で、ディスクを別のマシンへ載せ替えても構成を引き継げる可搬性が利点になります。パリティ計算をCPUで行うぶん負荷はかかりますが、現在のサーバーCPU性能なら実用上の問題は小さく、とくにZFSはデータ破損を検知して自動修復する仕組みを持つため、信頼性を重視する現場で選ばれています。専用機の性能と可搬性・コストのどちらを取るかが選び分けの軸です。

RAIDレベル(0/1/5/6/10)の違いと構成・容量効率・許容故障台数の比較

ここがRAID選定の核心です。各レベルは、速度・容量効率・耐障害性のどれを優先するかで性格が分かれます。代表的な5つのレベルを、仕組みと使いどころで順に見ていきます。

RAID0（ストライピング）とRAID1（ミラーリング）の仕組みと使いどころ

RAID0は、データを複数ディスクに分散して並列に書き込むストライピングだけの構成です。2台なら読み書きが理屈上ほぼ2倍に伸び、容量も全ディスクぶんをそのまま使えます。代償は耐障害性がゼロ、1台でも壊れればアレイ全体のデータが消える点です。壊れて困らない一時作業領域や、消えても元データから再生成できる編集用の中間ファイルなど、速度だけがほしい用途に限られます。対してRAID1は、同じ内容を2台へ同時に書くミラーリングです。片方が壊れても、もう片方がそのまま生き続けるため、読み書きを止めずに交換できます。容量は2台で1台ぶんに減り（半分）、速度は書き込みが単体並み・読み込みは分散で速くなります。台数が少なく確実に止めたくないOS領域や、小規模サーバーの起動ディスクに向く構成です。

RAID5とRAID6のパリティ計算の仕組みと許容故障台数の違い

RAID5は、データとパリティを全ディスクに分散して配置する構成です。最小3台で組め、1台ぶんの容量をパリティに使うため、実効容量は「全体からディスク1台ぶんを引いた量」になります。効率がよく、どれか1台が壊れても、残りのデータとパリティから故障ディスクの中身を計算で復元できるのが持ち味です。ただし耐えられるのは同時1台までで、リビルド中にもう1台壊れると全損します。RAID6は、このパリティを二重に持つ構成です。最小4台で、2台ぶんの容量をパリティに使うかわりに、同時2台の故障まで耐えられます。ディスクが大容量化しリビルドに時間がかかる現在、RAID5では再構築中の二次故障が現実的なリスクになるため、大型ドライブを多数束ねる構成ではRAID6が標準的な選択です。書き込み時にパリティを計算し直す必要があるぶん、両者とも書き込み性能はミラーリングより落ちる点は設計で織り込みます。この書き込みペナルティが実効のIOPS（1秒あたりの入出力回数）をどう目減りさせるかも合わせて押さえます。

RAID10（RAID1+0）の構成と書き込みの多いデータベースで選ばれる理由

RAID10は、RAID1（ミラー）でペアを作り、そのペア同士をRAID0（ストライピング）で束ねた構成です。最小4台で、容量は総量の半分になります。効率はRAID5/6に劣りますが、パリティ計算をしないため書き込みが速く、故障時の挙動も単純で読みやすいのが持ち味です。1台が壊れても、そのミラー相手が生きていればアレイは無傷で動き続け、リビルドもミラー相手からのまるごとコピーで済むため、パリティ再計算を伴うRAID5/6より短時間かつ低負荷で終わります。書き込みが多く、かつ止められないデータベースサーバーで第一候補になるのはこの特性ゆえです。容量効率を犠牲にしてでも、書き込み性能と復旧の速さ・確実性を取るのがRAID10の考え方になります。

各RAIDレベルの最小台数・容量効率・耐障害性を並べた比較表

選定の物差しとして、代表5レベルを主要な指標で並べます。実効容量のNはアレイを構成するディスクの総台数を指します。

RAIDレベル	主原理	最小台数	実効容量	同時故障の許容	リビルドの重さ	主な用途
RAID0	ストライピング	2台	N（全量）	0台（冗長性なし）	復旧不能	速度優先の一時領域
RAID1	ミラーリング	2台	N/2	1台	軽い（丸ごと複写）	OS・起動ディスク
RAID5	分散パリティ	3台	N−1台ぶん	1台	重い（全台読み直し）	容量効率重視の中小規模
RAID6	二重分散パリティ	4台	N−2台ぶん	2台	重い（全台読み直し）	大容量ファイル・保管
RAID10	ミラー＋ストライプ	4台	N/2	1台（各ペアで1台）	軽い（ペアから複写）	書き込みの多いDB

読み方の勘所は、上から下へ「速度・容量効率」から「耐障害性・書き込みの確実さ」へ重心が移る点です。容量効率だけならRAID5、耐障害性を足すならRAID6、書き込み性能と復旧の確実性まで求めるならRAID10、という順で判断すると外しません。右端から2列目のリビルドの重さは見落とされがちですが、故障してからの数時間から数日をどう過ごすかを決める指標で、選定の際は容量効率と同じ重みで見ます。RAIDを組む前提となるHDDとSSDの違いや容量の考え方はストレージの種類とHDD/SSDの違いの解説で整理しています。

mdadmでRAID6アレイを構築する手順とmdadm.confへの登録

比較表でレベルを決めたら、次は実際に組む作業です。ここではLinuxのmdadmでRAID6を作る流れと、ZFSでraidz2プールを作る流れを、そのまま打てるコマンドで示します。どちらも専用のRAIDカードを持たない汎用サーバーで動きます。

mdadm –createによるRAID6作成と同期状況のmdstat確認

4台のディスクでRAID6を組む場合、mdadm --create にレベルと台数、対象デバイスを渡すだけでアレイが立ち上がります。作成直後は全ディスク間でパリティを揃える初期同期が走り、その進行は/proc/mdstatに逐次表示されます。同期中もアレイは読み書きできますが、性能は落ちた状態です。各オプションの意味とメタデータ版の指定方法はmdadm(8)のmanページが一次情報になります。

# 4台でRAID6アレイを作成する
sudo mdadm --create --verbose /dev/md0 --level=6 --raid-devices=4 \
  /dev/sdb /dev/sdc /dev/sdd /dev/sde

# 初期同期の進み具合を確認する
cat /proc/mdstat

# 構成をmdadm.confへ書き出し、再起動後も同じ名前で組み立てる
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm.conf

# ファイルシステムを作ってマウントする
sudo mkfs.ext4 -L DATA01 /dev/md0
sudo mkdir -p /mnt/data01
sudo mount LABEL=DATA01 /mnt/data01

作った直後に済ませておきたいのが、3行目の構成書き出しです。これを飛ばすと、ディスクの認識順が変わったときにアレイ名がmd0からmd127へずれ、fstabのマウントが失敗して起動が止まる事故につながります。fstabにはデバイス名ではなくラベルかUUIDで書きます。あわせてnofailを付けておけば、ディスクが欠けた状態でもシェルまでは起動が進む挙動です。ここまでが構築の定型で、以降の運用はすべてこのアレイに対して行います。

ZFSでraidz2プールを作成しzpool statusで確認する手順

ファイルシステム側でRAID相当を持たせるなら、RAID6に対応するのがZFSのraidz2です。OpenZFSの公式ドキュメントは、raidzグループが単一・二重・三重のパリティを持ち、それぞれ1台・2台・3台の故障に耐えると定義しています（OpenZFS Docs: RAIDZ）。同じドキュメントは、1グループあたりのディスク本数を3〜9台に収めることを性能面から推奨しており、20台を1グループへ詰め込む構成は想定されていません。台数が増えるときは、9台以下のraidz2グループを複数並べてプールに束ねます。

# 4台でraidz2（二重パリティ）プールを作成する
sudo zpool create tank raidz2 sdb sdc sdd sde

# 冗長構成と各デバイスの状態を読む
zpool status tank

# 整合チェック（スクラブ）を回して進行を見る
sudo zpool scrub tank
zpool status -v tank

raidzはストライプ幅が固定ではなく、書き込むデータ量に応じて可変になります。公式ドキュメントの例では、recordsizeが128KBのとき3台構成のraidz1で利用効率は約66%とされ、台数が増えるほど容量効率が上がる計算です。逆に小さなファイルが大量に並ぶ用途では、パリティのオーバーヘッドが効率を押し下げるため、ミラーvdevのほうが素直な場合があります。ZFSを本番環境で使う土台としてのOSの選択肢はFreeBSDとLinuxの違い・ZFSやjailの実装の解説で扱っています。

ディスク故障からの復旧手順｜リビルド・ホットスペア・定期スクラブ

RAIDは組んで終わりではなく、ディスクが壊れてからが本番です。故障ディスクをどう切り離して交換するか、予備ディスクや電源をどう備えるか、そして壊れる前に不整合を見つける定期スクラブと、パリティ構成に潜む「ライトホール」という弱点を押さえます。

故障ディスクの切り離しと交換・リビルド開始までのmdadm操作

リビルドは、壊れたディスクを新品に交換したあと、残りのディスクとパリティから故障ディスクの中身を計算し直して書き戻す作業です。パリティ構成のRAID5/6では、アレイ内の全ディスクを最初から最後まで読み切ってパリティを再計算するため、容量が大きいほど時間がかかります。数TB級のドライブでは、リビルドが十数時間から数日に及ぶことも珍しくありません。手順そのものは3コマンドで完結します。

# 故障ディスクを故障扱いにしてアレイから外す
sudo mdadm --manage /dev/md0 --fail /dev/sdd --remove /dev/sdd

# 交換した新品を組み込む（自動でリビルドが始まる）
sudo mdadm --manage /dev/md0 --add /dev/sdd

# 予備をホットスペアとして登録しておく
sudo mdadm --manage /dev/md0 --add-spare /dev/sdf

# リビルドの進行率と推定残り時間を見る
cat /proc/mdstat

コマンドが短いぶん、危ないのはこの直後の時間帯です。リビルド中は残りのディスクをフル稼働で読み続けるため負荷が跳ね上がり、寿命が近い別のディスクがこのタイミングで巻き添え故障を起こしやすくなります。RAID5は同時1台しか耐えられないため、リビルド中の2台目の故障はそのまま全損です。さらに、大容量ドライブでは統計的に読み取り不能セクタ（URE）に当たる確率が上がり、リビルド中に1ブロックでも読めないと再構築に失敗する場合があります。これがRAID5を大型ドライブで避け、二重パリティのRAID6やミラーのRAID10を選ぶ最大の理由です。

ホットスペアとRAIDコントローラ・BBU（バッテリバックアップ）の役割

リビルドを速く確実にする備えが、ホットスペアとコントローラ周りの仕組みです。ホットスペアは、アレイに組み込まず待機させておく予備ディスクで、1台が故障すると人手を介さず自動でスペアが組み込まれ、リビルドが即座に始まります。故障から再構築開始までの時間を詰められ、二次故障までの危険な時間帯を短くできるのが利点です。RAIDコントローラは、ハードウェアRAIDで書き込みを制御する中核で、多くは書き込みを一時的にため込むキャッシュを持ち、応答を速くします。ここで必須になるのがBBU（バッテリバックアップユニット）またはフラッシュによるキャッシュ保護です。キャッシュにデータを保持したまま停電すると、書き込み途中のデータが失われますが、BBUがあれば電源復旧まで内容を保ち、データ整合性を守ります。キャッシュが階層のどこで効いているかという全体像は、ディスクキャッシュの仕組みとメモリキャッシュとの違いの解説で整理済みです。ハードウェアRAIDで書き込みキャッシュを有効にするなら、BBUの搭載と定期的な劣化チェックはセットで考えます。

sync_actionへのcheck投入で不整合を先に見つける定期スクラブ

故障してから慌てないために、壊れていないうちにアレイ全体を読み切って整合を確かめる作業がスクラブです。Linuxカーネルのmdドライバは、冗長性を持つレベル（1・4・5・6・10）に対してsync_actionというsysfsファイルを用意しており、ここにcheckと書き込むと冗長性の全体チェックが走ります。検出された不一致はmismatch_cntに、再書き込みが必要だった（checkの場合は必要だったはずの）セクタ数として積み上がります（Linuxカーネル md ドキュメント）。

# 冗長性の全体チェック（スクラブ）を開始する
echo check | sudo tee /sys/block/md0/md/sync_action

# 進行状況（完了セクタ数 ／ 総セクタ数）
cat /sys/block/md0/md/sync_completed

# 検出された不一致セクタ数
cat /sys/block/md0/md/mismatch_cnt

# 業務時間帯の負荷を抑えたい場合は同期速度の上限を下げる
echo 50000 | sudo tee /sys/block/md0/md/sync_speed_max

スクラブの狙いは、リビルド時に初めて発覚するUREを平時に洗い出すことにあります。月1回程度の周期で回し、mismatch_cntが増え続けるアレイは、ディスクの寿命かコントローラ側の疑いとして交換を前倒しする対象です。ZFSならzpool scrubが同じ役割を担い、チェックサム不一致を検出した時点でパリティから自動修復まで行います。運用に組み込むときは、同期速度の上限を下げて業務時間帯の影響を抑え、深夜帯に走らせる形が扱いやすい設定です。

RAID5/6のライトホールとPPL・ZFS（RAID-Z）での封じ方

パリティ構成には「ライトホール（write hole）」という構造的な弱点があります。RAID5/6では、データとパリティを別々のディスクへ書きますが、この2つの書き込みが完了する前に停電などで中断すると、データとパリティの整合が取れない中途半端な状態が残るのです。この不整合に気づかないまま、あとで別のディスクが故障してその領域を復元しようとすると、壊れたパリティから誤ったデータを再生成してしまう危険があります。ハードウェアRAIDでは前述のBBUやジャーナル（書き込みログ）でこの穴を塞ぐ方式です。Linuxのソフトウェアード構成では、RAID5向けにPPL（Partial Parity Log）という仕組みがあり、mdadm --consistency-policy=ppl で有効化できます。カーネルのドキュメントは、PPLが専用ジャーナルドライブを不要にして単一障害点を作らない反面、書き込み性能が最大30〜40%低下し、対応はRAID5の最大64ディスクまでだと明記しています（Linuxカーネル: Partial Parity Log）。ZFSのRAID-Zは、そもそも書き込みを上書きせず新しい場所へ書いてから切り替えるコピーオンライトの設計で、書き込みが原子的に完了するため、ライトホールが原理的に発生しません。整合性を最優先する現場でZFSが選ばれる理由の1つが、この構造的な安全性です。ディスク層のこうした無停止設計が、システム全体の無停止化とどう違うかはフォールトトレラントと高可用性・フェイルオーバーの違いの解説で扱っています。

企業がどのRAIDを選ぶか｜用途別の選定とRAIDはバックアップではない判断

ここは他社の解説が踏み込まない、RAID選定と運用方針を言い切る章です。原則は2つ、「RAIDレベルは用途（書き込み量・容量効率・停止許容度）から決める」ことと、「RAIDをバックアップの代わりにしない」ことです。この2点を外すと、費用をかけたのにデータを失う事故につながります。

用途別に選ぶRAIDレベルの基準（DB・ファイルサーバー・一時領域）

選定は用途で決め打ちできます。書き込みが多く止められないデータベースは、書き込みが速くリビルドも確実なRAID10が第一候補です。容量効率のためにRAID5を選びたくなりますが、書き込みのたびにパリティを計算するペナルティと、リビルドの遅さがDBでは重くのしかかります。大容量のファイルサーバーやアーカイブ、バックアップの保管先は、容量効率と二重故障耐性を両立するRAID6が基本です。ここでRAID5を大型ドライブで組むのは、前述のリビルドリスクから見送るべき典型例になります。速度だけがほしく、消えても再生成できる一時領域や動画編集の作業領域に限ってRAID0を使います。逆に言えば、消えて困るデータをRAID0に置くのは避けるべき構成です。台数が2台しか取れず確実に止めたくないOS領域はRAID1、という具合に、「書き込み量・容量効率・停止許容度」の3点で用途を分類すれば、レベルは一意に近く決まります。

「RAIDがあればバックアップ不要」という誤解と3-2-1の原則

最も多い、そして最も危険な誤解が「RAIDを組んだからバックアップは要らない」という考えです。RAIDが守るのは、あくまでディスクの物理故障だけです。オペレーターがファイルを誤って削除すれば、その削除操作はミラーにもパリティにも即座に反映され、全ディスクから同時に消えます。ランサムウェアによる暗号化も同様に全ディスクへ広がります。RAIDコントローラの不具合、筐体ごとの水没・火災・盗難、設定ミスによるアレイ破壊も、RAIDでは救えません。これらから守るのはバックアップの役目で、両者は代替関係ではなく役割分担です。指針となるのが3-2-1の原則で、データは3つの複製を持ち、2種類の異なる媒体に保存し、うち1つは物理的に離れた別拠点（オフサイト）へ置く、という考え方です。フル・差分・増分のどれをどう組み合わせるかという方式の選び方はシステムバックアップの種類と方式の選び方の解説にまとめました。RAIDはこのうち「稼働中のディスクを止めない」役割を担うにすぎず、過去の時点へ戻す復元は別に用意します。リビルドによるRAIDの復旧と、バックアップからの復元がどう違うかはリカバリーとリストア・バックアップの違いの解説で扱っています。

AWSがEBSでRAID5/6を勧めない理由とクラウド移行時の相談先

クラウドを使う場合、利用者が自前でRAIDを組む場面は大きく減りました。AWSのブロックストレージ（EBS）は、可用性ゾーン内の複数サーバーへデータを複製した状態で提供され、公式ドキュメントによれば一般的な市販ディスクの10倍の信頼性があるという説明です。そのうえで同ドキュメントは、EBS上でのRAID5とRAID6を明確に非推奨としています。理由はパリティ書き込みがボリュームのIOPSを食い、構成によってはRAID0比で使えるIOPSが20〜30%減るためで、同じ容量・速度ならRAID0の2ボリュームが、2倍のコストがかかるRAID6の4ボリュームを上回る場合があるとまで書かれています。RAID1も、書き込み帯域を余計に消費するうえ書き込み性能の向上がないとして勧められていません（AWS: Amazon EBS and RAID configuration）。クラウドで残る用途は、IOPSとスループットを積み増すためのRAID0だけ、と割り切るのが実務的な結論です。RAIDと役割の異なるオブジェクトストレージ（S3系）も内部で多重に複製されるため、自前RAIDの発想は不要で、この違いはオブジェクトストレージの仕組みとブロックとの違いの解説で整理しています。RAIDの設計判断が濃く残るのは、オンプレミスの物理サーバーや、性能要件からローカルディスクを束ねる一部の構成です。ディスク層の可用性が全体の可用性にどう組み込まれるかは稼働率と高可用性の設計の解説を参照してください。オンプレミスからクラウドへの移行を機にストレージ構成を見直したい、あるいは可用性目標に見合った基盤を設計したい場合は、要件整理から構成設計・実装までを一貫して支援できる開発会社に相談すると、過剰なRAID投資も、逆に冗長性不足の事故も避けられます。一創ではAWS/GCP/Azureでのストレージ冗長化を含むインフラ構築として、用途に見合ったディスク設計から運用まで対応しています。

RAIDに関するよくある質問｜RAIDレベル・バックアップ・故障についての疑問

これからRAID構成を設計する担当者や、既存アレイの運用を任された技術者から寄せられやすい質問に答えます。

RAID5とRAID6はどちらを選べばよいですか？

ディスクの容量と台数で決めます。数TB級の大型ドライブを4台以上束ねるなら、リビルド中の二次故障やURE（読み取り不能）に耐えられるRAID6が基本です。RAID5は同時1台までしか耐えられず、リビルドに時間のかかる大容量構成では再構築中の全損リスクが現実的になります。小容量ディスクを3台程度で組み、容量効率を優先したい中小規模ならRAID5でも成立しますが、迷ったら二重パリティのRAID6を選ぶ方が安全です。RAID5を使うなら、mdadmの--consistency-policy=pplでライトホールを塞ぐ設定もあわせて検討します。

RAIDを組めばバックアップは不要になりますか？

不要にはなりません。RAIDが守るのはディスクの物理故障だけで、誤削除・ランサムウェア・筐体ごとの災害・設定ミスには対応できません。これらの操作や被害は全ディスクへ同時に及ぶため、RAIDでは救えないのです。過去の時点へ戻す復元にはバックアップが別に必要で、データは3つの複製・2種類の媒体・1つは別拠点という3-2-1の原則で備えます。RAIDとバックアップは目的の違う別々の対策として両方を持ちます。

RAID10とRAID5+6では性能はどう違いますか？

書き込み性能と復旧の速さでRAID10が優位です。RAID5/6は書き込みのたびにパリティを計算し直すため書き込みが遅く、リビルドも全ディスクを読んで再計算するため時間がかかります。RAID10はパリティ計算がなく、リビルドも故障ディスクのミラー相手からのコピーで済むため、書き込みが速く復旧も短時間で終わる構成です。そのぶん容量は半分になるので、書き込みの多いDBはRAID10、容量効率がほしい保管用途はRAID6、と用途で使い分けます。

ホットスペアは必ず用意すべきですか？

止めたくないシステムでは用意する価値が高いです。ホットスペアがあると、ディスク故障の直後に人手を介さず自動でリビルドが始まり、二次故障までの危険な時間帯を短くできます。とくにリビルドに時間のかかる大容量のRAID5/6では、スペアの有無が全損リスクを分ける要因です。運用担当が常駐せず交換に時間がかかる環境ほど、ホットスペアの効果は大きくなります。あわせて月1回程度の定期スクラブを回し、mismatch_cntの増加を監視しておくと、故障の予兆を先に拾えます。

クラウドでも自分でRAIDを設計する必要がありますか？

ほとんどの場合は必要ありません。AWSのEBSやマネージドデータベース、S3系のオブジェクトストレージは、内部で複数拠点にまたがる冗長化が施された状態で提供されるため、利用者がディスク単位でRAIDレベルを設計する場面は限られます。AWSの公式ドキュメント自体がEBS上のRAID5/6/1を非推奨としており、クラウドで組む余地があるのは性能目的のRAID0だけです。RAIDの設計が残るのは、オンプレミスの物理サーバーや、性能要件からローカルディスクを束ねる一部の構成になります。