著者 VPSのRAID 10とは？NVMeで選ばれる理由
RAID 1、5、6、10が耐えられる故障台数、再構築のコスト、VPSホストがNVMeでRAID 10を選ぶ理由を解説します。/proc/mdstatの見方と、RAIDがバックアップではない理由も確認できます。
RAID 10 とは何か、VPS ホストが採用する理由
RAID 10 は、仮想化された NVMe（non-volatile memory express）ドライブ上で、ほとんどの VPS ホストが採用するストレージ構成です。一般的な 2 コピー構成では、各ドライブを別のドライブにミラーリングし、そのミラーリングされたペアにデータをストライピングします。1 台のドライブが故障してもアレイは停止せず、修復時にはセット内の他の全ドライブを読み取って再計算するのではなく、稼働しているペアから単純にコピーします。
RAID は redundant array of independent disks の略です。目的は 1 つだけです。ディスクが故障中または交換中でも、マシンによるサービス提供を継続することです。この目的は可用性であり、安全性とは異なります。
RAID は書き込みを複製します。rm -rf /srv は書き込みです。ミラーの両方が同じミリ秒内にそのディレクトリを失っても、アレイはその後も正常な状態だと報告します。
この文は覚えておいてください。このページの残りでは、各レベルがどの障害に耐えられるか、また書き込みのたびにどのようなコストが発生するかを説明します。最後のセクションでは、自分が所有するマシンでアレイの状態を確認するコマンドと、RAID では決して防げない障害を扱います。
ホスティングの利用者が実際に目にするレベル: 1、5、6、10
プランのページには数字だけが書かれていることがあります。この数字は、2 つの疑問に答えます。何台のドライブが故障しても耐えられるか、そして各書き込みにどのようなコストがかかるかです。
RAID 1 はミラーです。 2 台のドライブが同一のブロックを保持します。すべての書き込みは両方に行われます。どちらのドライブからでも読み取れます。1 台が故障してもデータは失われず、使用できる容量は raw 容量の半分です。計算するパリティがないため、書き込み経路は短くなります。
RAID 5 は、各ストライプに 1 つのパリティブロックを持つストライピングです。 n 台のドライブで、n-1 台分の容量を使用できます。アレイは 1 台の故障にだけ耐えられます。パリティは専用の 1 台に固定されません。すべてのドライブに分散されるため、各ドライブがデータとパリティの両方を保持します。
RAID 6 は、各ストライプに独立した 2 つ目のパリティブロックを追加します。 通常、これらは P と Q として書き込まれます。同時に 2 台のドライブが故障しても耐えられます。これは見た目以上に重要です。2 回目の故障は、最初の故障を修復している間に発生することが多いためです。
RAID 10 は、ミラーのストライプです。 ドライブを 2 台ずつミラーリングし、そのペア間にデータを分散します。使用できる容量は raw 合計の半分で RAID 1 と同じですが、ストライピングによる並列性が加わります。
RAID 1+0 と表記されることもあります。こちらが実態を正確に表しています。最初にミラーを作り、そのミラー間でストライピングします。RAID 0+1 は逆の順序で、最初にストライピングを行い、その 2 つのストライプをミラーリングします。こちらは劣ります。1 台のドライブが故障するとストライプ全体が利用できなくなり、修復時には反対側全体をコピーする必要があるためです。
Linux には、知っておく価値のある特殊な点があります。カーネルの raid10 は 2 つの層を重ねるのではなく、単一の personality として動作します。そのため、奇数台のドライブでも動作し、入れ子構成では表現できないレイアウト（near、far、offset）も使用できます。これが、Linux マシンのステータス行で 2 つのアレイを指定せず、2 near-copies と表示される理由です。
このグラフのデータ
[
{
"label": "RAID 1 (eight copies)",
"usable_tb": 1,
"worst_case_drives_lost": 7,
"best_case_drives_lost": 7
},
{
"label": "RAID 5",
"usable_tb": 7,
"worst_case_drives_lost": 1,
"best_case_drives_lost": 1
},
{
"label": "RAID 6",
"usable_tb": 6,
"worst_case_drives_lost": 2,
"best_case_drives_lost": 2
},
{
"label": "RAID 10",
"usable_tb": 4,
"worst_case_drives_lost": 1,
"best_case_drives_lost": 4
}
]1 TB のドライブ 8 台では、RAID 5 の使用可能容量は 7 TB、RAID 10 では 4 TB です。この差は実際の費用に影響します。そのため、パリティ方式が何度も提案されます。RAID 6 は、どのようなパターンでも 2 台の故障に耐えられます。RAID 10 が保証するのは 1 台だけです。危険な 2 回目の故障が、すでに故障したドライブのペア相手で発生する可能性があるためです。2 台の故障が同じペアに集中しなければ、最大 4 台まで耐えられます。ただし、これは設計上の特性ではなく、運によるものです。
各レベルで書き込みごとに必要になる処理
ミラーへの書き込みは 2 回の書き込みであり、両方のメンバーに同時に発行されます。パリティストライプへの書き込みでは、処理がさらに増えます。そのストライプのパリティブロックが正しくなくなるため、再計算が必要になるからです。
read-modify-write では、コントローラーが最初に古いデータと古いパリティを読み取ります。キャッシュされていない単一ブロックの上書きは、RAID 5 では read、read、write、write になります。RAID 6 では 2 つのパリティブロックを管理するため、read-modify-write は read、read、read、write、write、write になります。Linux は reconstruct-write も使用し、変更されていないデータを読み取ってパリティを計算します。3 台構成の RAID 5 では、その上書きに 1 回のデータ読み取りと 2 回の書き込みが必要になる場合があります。4 台構成の RAID 6 では、1 回のデータ読み取りと 3 回の書き込みです。4 と 6 は read-modify-write の処理回数であり、すべての小さなランダム書き込みに対する固定コストではありません。
このグラフのデータ
[
{
"label": "RAID 1 (2 drives)",
"write_ops_per_host_write": 2,
"drives_read_to_rebuild": 1
},
{
"label": "RAID 5 (8 drives)",
"write_ops_per_host_write": 4,
"drives_read_to_rebuild": 7
},
{
"label": "RAID 6 (8 drives)",
"write_ops_per_host_write": 6,
"drives_read_to_rebuild": 7
},
{
"label": "RAID 10 (8 drives, fixed mirror pairs)",
"write_ops_per_host_write": 2,
"drives_read_to_rebuild": 1
}
]キャッシュされていない単一ブロックの read-modify-write では、RAID 6 でデバイス操作が 6 回必要です。同じ上書きを 2 コピーの RAID 10 で行う場合は 2 回です。この回数だけでは、レイテンシの差は十分に表せません。2 つのミラー書き込みは並列に実行されるため、ゲストが待つ時間は遅い方の処理時間になります。read-modify-write では、新しいパリティを計算する前に読み取りを完了する必要があります。そのため、ゲストは読み取りの後に書き込みを待つことになり、処理は順番に実行されます。負荷の高いホストでは、その読み取りも他のすべての I/O の後ろでキューに入ります。
重要な例外があります。ストライプ全体を埋める大きさの書き込みでは、ストライプ内のすべてのブロックが置き換えられるため、古いデータは必要ありません。メモリ上にあるデータからパリティを計算できるため、先行読み取りなしで、RAID 5 ではストライプごとに 1 回、RAID 6 では 2 回のパリティ書き込みだけで済みます。これが、RAID 5 がシーケンシャルベンチマークでは問題なく見える一方、多数のテナントによる小さな書き込みが混在する負荷では性能が悪化する理由です。実際に運用するアクセスパターンでテストしてください。VPS ディスクを適切にベンチマークする には、1 回の大きな dd ではなく、現実的なキュー深度でのランダム I/O を使用します。
再構築が危険な理由
8 台構成の例では、完全な RAID 5 の再構築で、残りのすべてのドライブから故障したドライブを再構成する必要があります。そのため、最初のブロックから最後のブロックまで、7 台の正常なドライブを読み取ります。固定された 2 コピーのミラーペアでは、RAID 10 の再構築で読み取るのは 1 だけです。故障したドライブのミラーパートナーだけで、ほかのドライブは読み取りません。Linux RAID10 のほかのレイアウトでは、コピーの配置が異なります。3 デバイスの near レイアウトでメンバーを再構築する場合は、残りの 2 メンバーを読み取ります。
ここから 2 つのコストが生じます。1 つ目は時間です。再構築にかかる時間は、正常なドライブの性能、再構成処理、復旧速度の目標によって決まります。2 つ目は負荷です。パリティの再構築では、I/O が正常なドライブ全体に分散します。固定ミラーペアの RAID 10 では、その I/O が 1 つのペアに集中します。ただし、共有コントローラーとホストのリソースは、ほかのペアにも影響します。
同じ期間には、データの整合性に関するリスクもあります。1 台のドライブが故障した RAID 5 アレイには、冗長性が残っていません。そのため、正常なドライブのどこかに読み取り不能なセクターがあると、復旧できません。再構築では、1 年間誰もアクセスしていないセクターも含め、すべてのセクターを読み取ります。公開されているデータシートの数値では、コンシューマー向けハードドライブの読み取り不能エラーは、読み取り 10^14 ビットあたり 1 回程度です。エンタープライズ向け NVMe ドライブでは、10^17 ビットあたり 1 回以下です。これらは測定値ではなくベンダー仕様ですが、この比率から、RAID 5 の再構築は失敗するとする従来の警告が大容量の回転式ディスクを前提に書かれたことが分かります。また、NVMe ではその警告の妥当性が大幅に低くなります。負荷に関する説明は、どのメディアにも当てはまります。
再構築で潜在的なエラーが検出される前に、スクラブで検出してください。Debian と Ubuntu では md アレイ用の定期スクラブが提供されていますが、その仕組みはリリースによって異なります。使用している仕組みを確認してから、手動でパスを実行します。
systemctl list-timers --all | grep -i mdcheck
ls -l /etc/cron.d/mdadm
echo check | sudo tee /sys/block/md0/md/sync_action
cat /sys/block/md0/md/mismatch_cntパスが完了すると sync_action は idle に戻り、mismatch_cnt は 0 になるはずです。ミラーで 0 より大きい値が表示される場合、2 つのコピーの内容が一致していません。どちらが正しいかを kernel は判断できません。どちらのコピーにもチェックサムがないためです。ミスマッチの一部は問題ありません。通常の原因は swap パーティションです。kernel が書き込もうとしているページが、その処理中に変更されることがあるためです。データアレイでカウントが増加している場合は、調査が必要です。ただし、カウントだけでは交換すべきドライブは特定できません。
NVMe で VPS プロバイダーが RAID 10 を標準構成にする理由
ハイパーバイザーノードは、1 つのワークロードだけを実行するわけではありません。関係のないゲストを数十台実行し、それぞれの I/O が局所性のない小さな書き込みストリームとして混在して到着します。これは、パリティの read-modify-write サイクルのコストが最も大きくなるパターンです。共有ノードでは、この状態が終日続きます。
リビルド時の挙動を加味すると、選択は明確です。パリティ構成のノードでドライブが故障すると、残りのドライブ全体で再構成処理が発生します。固定ミラーペアで構成した RAID 10 ノードでは、故障したドライブのリビルド I/O は 1 組のペアに限定されます。また、ほかの処理が動作している場合、Linux MD はリカバリ速度を下げます。プロバイダーが提供するのは、レイテンシーが急増しないサービスです。そのために容量を使い、raw NVMe の半分をミラーに割り当てます。
ドライブの容量増加も同じ方向に作用します。ドライブが大容量になるほどリビルド期間は長くなります。RAID 5 では、その期間中に再構成による負荷が加わり、冗長性も失われます。RAID 6 なら、さらに 1 台のドライブが故障しても保護を維持できます。ZFS の仮想化環境で、幅の広い raidz ではなくミラー vdev のプールを使う理由も同じです。ミラーの resilver は、実際に使用中のブロックだけを 1 組のペア上でコピーします。
ただし、RAID 10 が常に正しいとは限りません。バックアップターゲットでは、長い連続領域として書き込み、読み取り頻度も低くなります。そのため、RAID 6 のほうが適しています。2 台の故障に耐えながら、容量の大部分を確保できます。判断基準は台数ではなく、ワークロードです。現在選ぶプランでは、通常、上位の RAID 構成よりも使用するメディアのほうが重要です。SATA SSD から NVMe への移行による差は、どちらのメディアでも RAID 構成による差を上回ります。
/proc/mdstat の読み方
自分が所有するアレイ上で実行してください。専用サーバー、自宅のマシン、または自分で組み立てた 2 つのボリュームを接続した VPS などが対象です。自分の出力を読み取ってください。以下のブロックは例です。実際の出力と形を比較できるよう、展開して記載しています。
cat /proc/mdstat
sudo mdadm --detail /dev/md0
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS正常な 4 ドライブの RAID 10 では、次のような出力になります。
Personalities : [raid1] [raid10]
md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2] nvme1n1p3[1] nvme0n1p3[0]
3906764800 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
bitmap: 0/30 pages [0KB], 65536KB chunk
unused devices: <none>この出力の各部分には情報があります。
Personalitiesは、実行中の kernel がロードした md モジュールを一覧表示します。raid10が表示されていることは、そのコードを利用できるという意味にすぎません。md0 : active raid10は、アレイデバイス、その状態、レベルを示します。- その後の名前はメンバーです。角括弧内の数字はアレイメタデータにおけるデバイスのインデックスです。行内の位置を示すものではなく、常にスロット番号と一致するとは限りません。
- ドライブ交換後は、新しいメンバーが、置き換えたスロットより大きいインデックスを持つことが一般的です。そのため、
nvme4n1p3[4]がスロット 2 に配置される場合があります。mdadm --detailはRaidDevice列に実際のスロットを表示するため、両者の違いが重要な場合はこちらを使用してください。 - メンバーの後にある
(F)は故障を示します。(S)はスペアを示します。スペアは存在しているもののアイドル状態で、何かが故障するのを待機しています。 3906764800 blocks super 1.2は使用可能なサイズを 1 KiB ブロック単位で示し、その後にメタデータ形式が続きます。512K chunks 2 near-copiesは stripe の chunk サイズと RAID 10 のレイアウトを示します。ここでは各ブロックのコピーを 2 つ、隣り合わせで保持します。[4/4]はアレイが想定するメンバー数と、現在同期しているメンバー数を示します。[UUUU]はスロットごとに 1 文字を、スロット順に表示します。Uは稼働中で同期済みのスロットです。_は動作しているものがないスロットです。bitmap:は write intent bitmap です。書き込み中だったリージョンを記録します。これにより、脱落したメンバーが復帰したとき、ドライブ全体ではなく該当リージョンだけを再同期できます。
[4/3] と [UU_U] が障害時に示す内容
劣化したアレイは次のように表示されます。
md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2](F) nvme1n1p3[1] nvme0n1p3[0]
3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]2 つの角括弧を一緒に確認してください。[4/3] は、4 スロットのうち 1 つが処理に参加していないことを示します。[UU_U] はそのスロットを示します。アンダースコアが 3 文字目にあり、スロット番号は 0 から始まるため、停止しているのはスロット 2 です。(F) フラグは、故障したドライブが接続されたままの間だけデバイス名を示します。マシンから取り外すと、その名前は行から消えますが、アンダースコアは残ります。
この状態でもアレイは処理を継続します。RAID 10 では、ほぼフルスピードで処理できることも多いため、体感だけでは異常に気付けません。別の方法で通知する必要があります。
grep -i mailaddr /etc/mdadm/mdadm.conf
sudo mdadm --monitor --scan --oneshot --test
systemctl list-units --all | grep -i mdmdadm パッケージは、/etc/mdadm/mdadm.conf から MAILADDR を読み取る監視 daemon をインストールします。unit 名は release によって変わっているため、推測せず、最後の command で確認してください。--test の実行時には、各アレイについて直ちに 1 通ずつメッセージを送信します。実行後に inbox が空なら、mail 経路に問題があります。実際に必要なメッセージも同じように失われていたことになります。
交換用ドライブを使って再構築していると、アレイの下に進捗行が表示されます。
md0 : active raid10 nvme4n1p3[4] nvme3n1p3[3] nvme1n1p3[1] nvme0n1p3[0]
3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]
[==>..................] recovery = 12.4% (242012928/1953382400) finish=63.1min speed=452000K/secrecovery は交換用ドライブへの再構築です。resync は整合性チェックです。初回のチェックと、正常でない shutdown からの復旧も含まれます。check は、上で実行した scrub です。括弧内の組み合わせは、デバイスごとの合計に対する進捗を 1 KiB ブロック単位で示します。finish は、現在の速度に基づく kernel の推定残り時間です。Linux MD は /proc/sys/dev/raid/speed_limit_min と speed_limit_max を recovery 速度の目標値として使用し、アレイごとの上書き設定を sync_speed_min と sync_speed_max に持ちます。既定の最大目標値はデバイスごとに 200,000 KiB/s です。これらの目標値により、recovery は本番 I/O に処理時間を譲れます。速度を固定する上限ではありません。
再構築中の完全な mdadm --detail
/dev/md0:
Version : 1.2
Creation Time : Tue Mar 10 09:14:22 2026
Raid Level : raid10
Array Size : 3906764800 (3.64 TiB 4.00 TB)
Used Dev Size : 1953382400 (1.82 TiB 2.00 TB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Update Time : Wed Aug 5 11:02:41 2026
State : clean, degraded, recovering
Active Devices : 3
Working Devices : 4
Failed Devices : 0
Spare Devices : 1
Layout : near=2
Chunk Size : 512K
Rebuild Status : 12% complete
Name : storage:0
Events : 4184
Number Major Minor RaidDevice State
0 259 3 0 active sync set-A /dev/nvme0n1p3
1 259 7 1 active sync set-B /dev/nvme1n1p3
4 259 11 2 spare rebuilding /dev/nvme4n1p3
3 259 15 3 active sync set-B /dev/nvme3n1p3Number 列は、/proc/mdstat の角括弧内に表示されるメタデータのインデックスです。RaidDevice 列はスロットです。[UU_U] 文字列内の位置に相当します。ここで両者が異なるのは、デバイス 4 がスロット 2 を保持していたドライブを置き換えたためです。set-A と set-B は、各 mirror の 2 つの側を示します。同じペア内で同じデータを保持する set-A のメンバーと set-B のメンバーを、同時に失わないことが重要です。
自分が所有するアレイでドライブを交換する操作は 4 command です。最後の command が確認になります。
sudo mdadm --manage /dev/md0 --fail /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --remove /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --add /dev/nvme4n1p3
cat /proc/mdstatrecovery 行は 1 秒か 2 秒以内に表示されるはずです。交換用 partition は、mdadm --detail の Used Dev Size 以上のサイズでなければなりません。わずかでも小さい partition は、not large enough to join array のようなメッセージとともに拒否されます。追加する前に、新しいドライブを古いドライブと同じ構成に partitioning してください。
VPS の内部から確認できることとできないこと
ほとんどのゲスト OS はホスト側の RAID を認識できません。これは意図的な仕様です。ハイパーバイザーは 1 つの仮想ディスクのみをゲストに提供します。そのディスクが NVMe ドライブの RAID 10 プールから切り出されたものか、単一のドライブ上にあるかはホスト側のプロパティであり、ゲスト内部には表示されません。
systemd-detect-virt
lsblk -d -o NAME,SIZE,ROTA,MODEL
cat /proc/mdstatsystemd-detect-virt は、KVM ゲストでは kvm、lxc のようなコンテナ種別では lxc、ベアメタルでは none を出力します。KVM ゲストでは通常、lsblk に単一の vda または sda が表示され、/proc/mdstat にアレイは表示されません。ゲスト内部には存在しないためです。
コンテナベースの VPS では、読み取れる情報は信頼できません。コンテナはホストのカーネルを共有しており、/proc の一部は名前空間（namespace）で分離されていないため、そこに表示される内容は自身のスライスではなくホストの情報を記述している可能性があります。これらを自身のストレージに関する事実として扱わないでください。構成についてはプロバイダーに問い合わせ、重要であれば回答を書面で入手してください。
内部から確認できるのは、提供されたディスクの挙動です。VPS のディスクが本当に NVMe かを確認する方法 では実際に有効な情報を報告するコマンドを解説し、SSD VPS に実際に含まれるもの ではプランページ上のラベルが何を主張しているのかを解説します。
VPS 内で RAID を構成すべきですか？
通常は構成しません。理由は障害ドメインです。1 台の VPS に 2 つのボリュームを接続し、mdadm でミラーリングしても、両方のボリュームが同じ物理アレイ、同じノード、同じ電源装置の配下にある可能性があります。すでに確保されている冗長性のために、すべての書き込みコストを 2 倍にしても、重要な 1 つの障害で両方のコピーを失うことになります。
プロバイダーがボリュームを別々の障害ドメインに配置していることを明記している場合や、ドライブを自分で指定できる dedicated server を使用している場合は、構成する価値があります。それ以外の場合は、マシンの外部に保存されるコピーに取り組むほうが効果的です。
RAID では防げないこと
RAID が対処できるのは、ドライブが正常に動作しなくなるという 1 つの事象です。以下はいずれも正当な書き込みです。そのため、アレイはすべてのコピーに反映し、自身を正常と報告します。
- 削除。 間違ったディレクトリで
rm -rfを実行した場合や、パス内の変数が未設定のままデプロイスクリプトを実行した場合です。アレイは正当な書き込みとして認識し、2 つのドライブに反映します。 - ランサムウェア。 暗号化は書き込みです。正常なアレイは、ミラーの両方に暗号化されたデータを保存します。
- 壊れたアプリケーション。 データベースに不正なデータを書き込むバグがあると、冗長化されたドライブにも同じ不正なデータが書き込まれます。
- ノード全体。 ホストが停止した場合や、アカウントが誤って停止された場合です。アレイが完全に正常でも、同時にアクセス不能になることがあります。
- 後から気づいた自分自身の操作。 月曜日に削除したファイルは、その時点で全ドライブから消えています。それより前に取得したコピーだけが復元に役立ちます。
同じストレージ上のスナップショットも解決策にはなりません。削除への対策にはなりますが、保存先のアレイとともに失われます。バックアップをバックアップにする性質は、別の場所に存在することです。restic による暗号化オフサーバーバックアップは、このページのもう一方の要点です。アレイはドライブが故障してもサービスの提供を継続し、restic はアレイが問題ない書き込みとして受け入れた変更によってデータが破損した場合に、データを復元します。
FAQ
RAID 10 ならバックアップは不要ですか？
いいえ。RAID 10 は、ドライブが停止した場合の障害に備えるものです。ミラーの両方にすべての有効な書き込みを適用するため、削除やランサムウェアによる処理も、同じ瞬間に冗長側のドライブへ反映されます。アレイはその後も正常と報告します。アレイから見ると、障害は何も発生していないためです。マシンの外部に保存するコピーが必要です。また、コピーから実際に復元できることを確認するため、定期的に復元テストを行う必要があります。
VPS プロバイダーが RAID 5 や RAID 6 ではなく RAID 10 を選ぶのはなぜですか？
理由は 2 つあります。どちらも、小さなランダム書き込みに関係します。キャッシュされていない単一ブロックの read-modify-write では、新しいパリティを計算する前に古いデータとパリティを読み取ります。そのため、RAID 5 では 4 回、RAID 6 では 6 回の処理が必要です。2 コピーのミラーでは 2 回です。reconstruct-write では、変更されていないデータを使用します。また、full-stripe write では古いデータや古いパリティを事前に読み取る必要がありません。RAID 5 の完全な再構築では、残っているすべてのドライブを先頭から末尾まで読み取ります。一方、従来の RAID 10 では、固定されたミラーペアの生きている側からコピーします。Linux RAID10 の別のレイアウトでは、複数のソースメンバーを使用します。ほかの処理が動作している間、Linux MD はリカバリを抑制します。プロバイダーは、その代償として容量を負担します。使用できる容量は、raw NVMe の半分です。
/proc/mdstat の [U_] や [UU_U] は何を意味しますか？
各文字は、アレイ内の 1 つのスロットをスロット順に表します。スロットごとに 1 文字が割り当てられます。U は、そのスロットに稼働中で同期済みのメンバーがあることを示します。_ は、そのスロットで動作しているものがないことを示します。2 ドライブのミラーで [U_] が表示された場合、2 番目のスロットが停止しており、冗長性が残っていないことを示します。前に表示されるペアと合わせて読みます。[4/3] は、アレイが 4 メンバーを想定し、そのうち 3 つが存在することを示します。スロットの順序は、mdadm --detail の RaidDevice 列と一致します。行にデバイス名が表示される順序とは一致しません。
RAID 10 アレイでは、ドライブを何台失っても大丈夫ですか？
固定されたミラーペアを使用する従来の 2 コピー RAID 10 では、どのようなパターンでも 1 台です。それを超えると、障害がどこで発生したかによって異なります。各ミラーペアは 2 台のうち 1 台を失っても動作するため、8 ドライブのアレイでは、同じペアに 2 台の障害が発生しなければ、最大 4 台の障害に耐えられます。一方、同じペアの 2 台が故障すると、2 台の障害で停止します。保証される台数である 1 台を基準に計画してください。それを超える分は保護ではなく、運がよかっただけと考えます。
VPS 内の 2 つのボリュームを mdadm でミラーすべきですか？
通常は不要です。1 台の VPS に接続された 2 つのボリュームは、同じホスト上の同じ物理アレイに配置されていることが多いためです。その場合、すべての書き込みコストが 2 倍になるだけで、ホスト自身の RAID がすでに防いでいる障害に対する追加の保護にはなりません。プロバイダーが、ボリュームを別々の障害ドメインに配置していると明示している場合に限り、実施する価値があります。それ以外の場合は、その作業をマシンの外部に保存するバックアップに充ててください。