RAIDとLVM入門｜ディスクの冗長化とボリューム管理をサーバー運用で使いこなす

「サーバーのディスクが1本壊れたら、サービスは止まるのか」「後から容量を増やしたいとき、どうやって広げるのか」。物理サーバーを扱う場面はもちろん、クラウドでも「EBSはRAIDにすべきか」「LVMは必要か」といった判断を求められることがあります。RAIDとLVMはどちらも古くからある技術ですが、役割を混同したまま運用されているケースが少なくありません。

この記事では、RAID 0/1/5/6/10の違いと「RAIDはバックアップではない」と言われる理由、LinuxのソフトウェアRAIDツールmdadmでの構築と監視、LVMの3層構造（物理ボリューム・ボリュームグループ・論理ボリューム）と無停止での拡張手順、そしてクラウドのブロックストレージ（EBSや永続ディスク）ではどこまでが不要になるのかを解説します。ファイルシステムの選択はLinuxファイルシステム入門、dfやmountの基本はLinuxのディスク管理入門を前提とします。

RAIDの種類と違い

RAIDが解決する2つの問題

RAID（Redundant Array of Independent Disks）は複数のディスクを束ねて1つのディスクのように見せる技術で、目的は「ディスク1本の故障でデータを失わない（冗長性）」と「複数本に分散して読み書きを速くする（性能）」の2つです。どちらをどの程度重視するかで、レベルと呼ばれる構成が分かれます。

レベル	仕組み	最低本数	実効容量	耐えられる故障	特徴
RAID 0	ストライピング（分散書き込み）	2	全本数分	0本	速いが1本壊れると全滅
RAID 1	ミラーリング（同じ内容を複製）	2	1本分	1本	単純で復旧が容易。OS領域の定番
RAID 5	ストライピング＋パリティ1つ	3	本数−1	1本	容量効率が良いが書き込みが遅く再構築が長い
RAID 6	ストライピング＋パリティ2つ	4	本数−2	2本	再構築中の2本目故障に耐える
RAID 10	ミラーをストライピング	4	半分	各ミラー1本ずつ	速くて堅い。DB向けの定番

大容量ディスク時代の注意点

RAID 5は容量効率の良さから長く使われてきましたが、ディスクが数TB規模になると再構築（故障ディスクを交換して残りのディスクから内容を計算し直す処理）に数時間から数日かかり、その間に2本目が故障したり読み取りエラーが出たりすると全データを失います。再構築中は全ディスクにフル負荷がかかるため、故障が連鎖しやすい点も見逃せません。このため、大容量ディスクではRAID 6かRAID 10を選ぶのが現在の一般的な判断です。

「RAIDはバックアップではない」の意味

RAIDが守るのは「ディスクという部品の物理故障」だけです。誤ってrm -rfしてしまったファイル、ランサムウェアで暗号化されたデータ、アプリのバグで壊れたレコードは、RAIDによって即座に全ディスクへ忠実に複製されます。RAIDコントローラーの故障や火災・水害にも無力です。冗長化は「止まらないため」、バックアップは「戻すため」の仕組みであり、両方が必要です。バックアップの考え方はバックアップ3-2-1ルールを参照してください。

mdadmでソフトウェアRAIDを構築する

RAID 1を組む手順

Linuxではカーネルのmd機能とmdadmコマンドで、専用ハードウェアなしにRAIDを構成できます。ここでは/dev/sdbと/dev/sdcでRAID 1を組みます。

1. 対象ディスクにデータがないことを確認し、RAIDアレイを作成します。

   sudo apt install mdadm
   lsblk    # sdb, sdc が未使用であることを確認
   sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc

2. 同期の進行状況を確認します。初回は全領域をコピーするため時間がかかりますが、同期中でも使用できます。

   cat /proc/mdstat
   # md0 : active raid1 sdc[1] sdb[0]
   #       976630464 blocks super 1.2 [2/2] [UU]
   #       [==>..................]  resync = 12.3% (120000000/976630464)
   sudo mdadm --detail /dev/md0

3. ファイルシステムを作ってマウントし、設定を保存して再起動後も認識されるようにします。

   sudo mkfs.xfs /dev/md0
   sudo mkdir /data && sudo mount /dev/md0 /data
   sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
   sudo update-initramfs -u    # Debian/Ubuntu

[UU]が両ディスク正常の印で、故障すると[U_]のように表示されます。故障ディスクはmdadm --failと--removeで外し、交換後にmdadm --add /dev/md0 /dev/sddで組み込むと自動的に再構築が始まります。

監視を必ず設定する

ソフトウェアRAIDで最も多い事故は「片方が壊れていたのに誰も気づかず、もう片方が壊れて全損」です。RAID 1は1本壊れても何事もなく動き続けるため、監視がなければ故障に気づけません。mdadm --monitor（多くのディストリビューションではmdmonitorサービスとして常駐）に通知先メールを設定するか、/proc/mdstatを監視ツールで定期的に確認する仕組みを必ず入れてください。

LVMの3層構造と拡張手順

PV・VG・LVの関係

LVM（Logical Volume Manager）は、物理ディスクとファイルシステムのあいだに抽象層を挟み、容量の追加や分割を柔軟にする仕組みです。3つの概念で構成されます。

• PV（Physical Volume）：LVMの材料となる物理ディスクやパーティション、RAIDアレイ（/dev/md0もPVにできます）
• VG（Volume Group）：複数のPVを束ねた容量のプール
• LV（Logical Volume）：VGから切り出した論理的なディスク。ここにファイルシステムを作ってマウントします

この構造により、「ディスクを追加してVGに入れれば、LVを後から広げられる」「1つのVGから/var/lib/mysql用と/var/log用のLVを別々に切り出し、ログの肥大化がDBを圧迫しないようにする」といった運用が可能になります。RAIDが「壊れないようにする」技術なら、LVMは「後から変えられるようにする」技術です。

無停止で容量を拡張する

LVMの最大の利点は、サービスを止めずに容量を増やせることです。新しいディスク/dev/sddを追加して、既存のLVを拡張する手順は次のとおりです。

# 現状確認
sudo pvs; sudo vgs; sudo lvs

# 新ディスクをPV化してVGに追加
sudo pvcreate /dev/sdd
sudo vgextend vg_data /dev/sdd

# LVを50GB拡張し、ファイルシステムも同時に拡張（-r）
sudo lvextend -r -L +50G /dev/vg_data/lv_mysql

# VGの空き全部を使う場合
sudo lvextend -r -l +100%FREE /dev/vg_data/lv_mysql

df -h /var/lib/mysql

-r（--resizefs）を付けると、ext4ならresize2fs、XFSならxfs_growfsを自動で呼び出してくれます。付け忘れるとLVは広がってもファイルシステムが古いサイズのままで「拡張したのに容量が増えない」状態になるので注意してください。またLVMにはスナップショット機能もあり、lvcreate -sで取得した瞬間の状態を固定してからバックアップを取ることで、DBファイルの整合性を保ったコピーが作れます。

クラウドのブロックストレージとの対応関係

EBS・永続ディスクではRAIDの意味が変わる

AWSのEBS、GCPの永続ディスク、AzureのManaged Disksといったクラウドのブロックストレージは、クラウド側で複数の物理ディスクに複製されており、ディスク1本の物理故障はユーザーからは見えません。そのため冗長性のためのRAID 1/5/6は不要です。代わりに、複数ボリュームをRAID 0で束ねてIOPSやスループットを合算する使い方が残っていますが、ボリュームサイズやタイプで性能を上げられる現在では必要な場面は限られます。

冗長化の役割はスナップショット（EBSスナップショット等）とマルチAZ配置に置き換わります。ただしスナップショットはあくまでバックアップであり、「RAIDはバックアップではない」の裏返しとして、「クラウドの複製も誤操作からは守ってくれない」点は変わりません。

LVMはクラウドでも有効

一方、LVMはクラウドでも十分に役立ちます。EBSは稼働中にサイズを拡張できますが、その後にパーティションとファイルシステムを広げる作業が必要で、LVMを挟んでおけばlvextend -rで一貫した手順になります。また複数の小さなボリュームをVGにまとめて用途別のLVを切る、といった設計もそのまま使えます。EC2の運用でデータ領域を別ボリュームにするなら、最初からLVMにしておくと後の変更が楽です。ブロックストレージとオブジェクトストレージの使い分けはストレージの種類の解説で扱います。

トラブル事例：RAID 1なのに全データを失った

症状：社内のファイルサーバー（RAID 1）が突然起動しなくなり、両方のディスクが認識されない。

原因：調べると、片方のディスクは8か月前に故障して[U_]状態になっており、その間ずっと1本だけで稼働していた。監視もメール通知も設定されておらず、誰も気づかないまま2本目が故障した。バックアップは「RAIDだから大丈夫」という理由で取られていなかった。

対処：専門業者によるデータ復旧で一部を回収したが、完全には戻らなかった。再発防止として、mdmonitorのメール通知と監視ツールでの/proc/mdstatチェックを設定し、外部ストレージへの日次バックアップと月1回の復元テストを運用に組み込んだ。冗長化は「気づいて交換する」までがセットであり、監視のないRAIDは冗長化として機能していない、というのがこの事例の教訓です。

まとめ

RAIDはディスクの物理故障に備える冗長化技術で、小規模ならRAID 1、性能と堅牢性を両立するならRAID 10、大容量ならRAID 6が基本線です。ただし誤操作やランサムウェアには無力なので、バックアップは別に必要です。LVMはPV・VG・LVの3層で容量を抽象化し、lvextend -rによる無停止拡張とスナップショットを提供します。クラウドではブロックストレージ自体が複製されているため冗長化目的のRAIDは不要になりますが、LVMによる拡張のしやすさは引き続き有効です。まずは自分のサーバーでcat /proc/mdstatとlvsを実行し、現在の構成と監視の有無を確認してみてください。

ストレージ構成の設計やバックアップ運用の整備でお困りの際は、Harmonic Societyのシステム開発・インフラ支援にご相談ください。