LVMとは｜Linuxで論理ボリュームを拡張する方法
※本記事にはプロモーションを含む場合があります。
- LVMは稼働中のLinuxサーバーでもディスク容量をオンライン拡張できる仕組みで、ダウンタイムをほぼゼロに抑えられるとされています
- PV（物理ボリューム）→VG（ボリュームグループ）→LV（論理ボリューム）という3階層構造を理解すれば操作の8割は迷わなくなります
- 拡張作業はpvcreate・vgextend・lvextend・resize2fs（またはxfs_growfs）の4コマンドが基本の型です
- ext4とXFSでは拡張時の挙動が異なり、XFSはマウント中でないと拡張コマンドが通らない点に注意が必要です
- 「No space left on device」など代表的な5つのエラーはパターン化されており、原因を切り分ければ数分で復旧できるケースが多いとされています
LVMとは何か
Linuxサーバーを運用していると、ログの肥大化やデータベースの増加によって「あと10GBだけ足りない」という場面に必ずといっていいほど遭遇します。従来のパーティション方式では、ディスクの再フォーマットやデータの退避が前提になり、作業時間が半日から1日がかりになることも珍しくありませんでした。LVM（Logical Volume Manager）は、この問題をサービス無停止のまま解決するために設計された、Linuxカーネル標準のストレージ抽象化レイヤーです。
LVMの仕組みを一言で表すと、物理ディスクをいったん「プール」にまとめ、そこから必要な分だけ仮想的な区画（論理ボリューム）を切り出すというモデルです。物理ディスクを1本追加してVGに組み込むだけで、既存の論理ボリュームへ容量を継ぎ足せます。実測環境では、100GBのディスクをpvcreateからmount完了まで通しても、コマンド操作自体は5分前後で終わるケースが多いとされています。
特に効果を発揮するのは、Webサーバーのログ領域やデータベースのデータ領域など、成長予測が難しい用途です。ディスク使用率が80%を超えた時点でアラートを設定しておき、閾値を超えたら物理ディスクを追加してvgextend・lvextendを実行する、という運用フローを組んでいる現場も少なくありません。従来方式であれば数時間かかっていた復旧作業が、LVMなら数分で完了する点は大きな差になります。
一方で、LVM自体はRAIDや暗号化の代替にはならない点も押さえておく必要があります。ミラーリング機能はありますが、ハードウェアRAIDほどの性能や信頼性を保証するものではないとされています。用途に応じてRAIDコントローラーやZFSなど他の技術と使い分ける判断も求められます。
主要用語を押さえる
LVMのドキュメントやエラーメッセージには、PV・VG・LV・PE・LEといった略語が頻出します。これらを理解しないままコマンドを打つと、意図しない領域を初期化してデータを消失させるリスクがあるため、最初にしっかり整理しておきます。
| 用語 | 正式名称 | 役割 | 代表コマンド |
|---|---|---|---|
| PV | Physical Volume（物理ボリューム） | 実ディスクやパーティションをLVM管理下に置く最小単位 | pvcreate / pvdisplay |
| VG | Volume Group（ボリュームグループ） | 複数のPVを束ねたストレージプール | vgcreate / vgextend |
| LV | Logical Volume（論理ボリューム） | VGから切り出した仮想パーティション。マウント対象 | lvcreate / lvextend |
| PE | Physical Extent（物理エクステント） | PV内の最小管理単位。既定値は4MiBとされています | 直接操作は少ない |
| LE | Logical Extent（論理エクステント） | LV内の最小管理単位。PEと同サイズで対応 | 直接操作は少ない |
この階層構造を家に例えるなら、PVは「土地」、VGは「複数の土地をまとめた分譲地」、LVは「分譲地の中に建てた家」に近いイメージです。土地（PV）を1区画買い足せば、分譲地全体（VG）の面積が増え、その分を既存の家（LV）の敷地拡張に回せる、という関係になります。100GBのディスク1本を新規PVとして追加すれば、VGの空き容量はそのまま100GB増加します。
導入前の準備は？
LVMを使い始める前に、対象サーバーの環境確認とパッケージインストールを行います。CentOS 7/8、RHEL 7/8、Ubuntu 20.04/22.04など主要ディストリビューションでは、lvm2パッケージが標準リポジトリに含まれており、インストール自体は1〜2分で完了するとされています。
- root権限またはsudo権限が使えるアカウントでログインする
- lsblkコマンドで拡張対象の物理ディスク（例: /dev/sdb）が認識されているか確認する
- CentOS/RHEL系は「sudo yum install -y lvm2」、Ubuntu/Debian系は「sudo apt install -y lvm2」を実行する
- 対象ディスクにパーティションテーブルが残っている場合はfdiskで削除し、まっさらな状態にする
- pvcreateコマンドで物理ボリュームとして初期化する
この段階で最も事故が起きやすいのが、fdiskで削除対象のディスクを取り違えるケースです。lsblkの出力で容量とマウント状態を必ず突き合わせ、稼働中の/(ルート)や/bootが載ったディスクを誤って初期化しないよう、作業前にディスクIDやシリアル番号もあわせて確認する運用が推奨されています。
- □ 対象ディスクのデバイス名（/dev/sdbなど）を確認した
- □ lsblkの出力で稼働中のディスクと混同していないか確認した
- □ 重要データがあるディスクではないことを確認した
- □ lvm2パッケージのインストールが完了している
- □ 作業ログを残す準備（scriptコマンドや作業メモ）ができている
準備が整ったら、pvcreate /dev/sdbで物理ボリュームを作成し、vgcreate vg_data /dev/sdbでボリュームグループを作成します。この時点で、pvdisplayやvgdisplayを実行し、想定通りのサイズ（例: 100.00 GiB）が表示されているかを必ず確認してください。数値がずれている場合は、別のディスクを掴んでいる可能性があります。
ボリューム作成手順
VGが準備できたら、実際にマウントして使う論理ボリュームを作成します。以下は50GBのLVを作成し、ext4でフォーマットして/mnt/appにマウントするまでの一連の流れです。
- lvcreate -n lv_app -L 50G vg_dataでLV名「lv_app」・サイズ50GBの論理ボリュームを作成する
- lvdisplayで作成結果（LV Size 50.00 GiBなど）を確認する
- mkfs.ext4 /dev/vg_data/lv_appでファイルシステムを作成する（XFSの場合はmkfs.xfs）
- mkdir /mnt/appでマウントポイントを作成する
- mount /dev/vg_data/lv_app /mnt/appでマウントし、df -h /mnt/appでサイズを確認する
- /etc/fstabにエントリを追記し、再起動後も自動マウントされるよう設定する
mkfs.ext4の処理時間は、50GB程度のLVであれば数十秒からおよそ2分程度で完了するとされています。処理中に電源断が発生するとファイルシステムが破損する恐れがあるため、UPS未導入の環境では特に注意してください。/etc/fstabへの追記を忘れると、再起動後にマウントが外れた状態になり、アプリケーションがルートパーティションへ書き込みを始めてディスクを圧迫する二次障害につながるケースも報告されています。
fstab設定後は、必ず「sudo mount -a」を実行して構文エラーがないか確認します。ここでエラーが出た場合、再起動時にサーバーがブートに失敗する可能性があるため、本番機での作業前には検証環境での事前確認が推奨されています。
拡張の実践ステップ
LVMの本領が発揮されるのが、稼働中システムでの容量拡張です。ここでは、既存のvg_data（100GB）に新規ディスク/dev/sdc（100GB）を追加し、lv_appを50GBから100GBへ拡張する例を扱います。
| 手順 | コマンド | 目的 | 所要時間の目安 |
|---|---|---|---|
| 1. 現状確認 | vgdisplay vg_data | 空き容量の把握 | 数秒 |
| 2. PV追加 | pvcreate /dev/sdc | 新ディスクの初期化 | 数秒〜1分 |
| 3. VG拡張 | vgextend vg_data /dev/sdc | プール容量の増加 | 数秒 |
| 4. LV拡張 | lvextend -L +50G /dev/vg_data/lv_app | 論理ボリュームの拡張 | 数秒 |
| 5. FS拡張 | resize2fs または xfs_growfs | ファイルシステムへの反映 | データ量に応じて数秒〜数十分 |
この手順の中で最も時間がかかるのは、意外にもresize2fs・xfs_growfsのステップです。既存データ量が少ない状態（数十MB程度）であれば数秒で終わりますが、数百GB〜TB級のファイルシステムでは処理に数十分を要する場合があるとされています。深夜バッチの直前など、負荷が集中する時間帯を避けて実施するのが安全です。
拡張量の指定方法は2通りあります。「-L +50G」は現在のサイズに50GBを追加する相対指定、「-L 100G」は拡張後のサイズを絶対値で指定する方法です。運用中は相対指定の方が計算ミスを防ぎやすいため、多くの現場でこちらが標準として使われているとされています。また「-l 100%FREE」を使えば、VG内の空き領域をすべて1回のコマンドでLVに割り当てることも可能です。
ファイルシステム拡張
lvextendでLVのサイズを増やしただけでは、OS上で認識できる容量は変わりません。df -hで見えているサイズを実際に増やすには、ファイルシステムごとの拡張コマンドを別途実行する必要があります。この工程を忘れると「lvdisplayでは100GBなのにdf -hでは50GBのまま」という状態になり、問い合わせの多いトラブルのひとつになっています。
| 項目 | ext4 | XFS |
|---|---|---|
| 拡張コマンド | resize2fs /dev/vg_data/lv_app | xfs_growfs /mnt/app（マウントポイント指定） |
| オンライン拡張 | 可能 | 可能（マウント中のみ） |
| 縮小対応 | 可能（アンマウント時のみ） | 非対応 |
| 理論上の最大サイズ | 1EB程度とされています | 8EB程度とされています |
| 反映速度 | データ量に比例 | 比較的高速とされています |
ext4の場合、拡張対象はデバイスパス（/dev/vg_data/lv_app）を指定します。一方でXFSの場合はデバイスパスではなく、マウントポイント（/mnt/app）を指定する点が最大の違いです。この違いに気づかずデバイスパスを指定してエラーになる相談は、現場でも一定数見られるとされています。
拡張後は必ずdf -h /mnt/appで容量を確認し、想定通りのサイズになっているかをチェックします。あわせて、複数台のLVを定期的に拡張する運用がある場合は、ファイルシステムの種類を自動判定して分岐するシェルスクリプトを組んでおくと、手作業によるコマンド間違いを減らせます。df -Tでファイルシステムの種類を取得し、条件分岐でresize2fsとxfs_growfsを呼び分ける構成が一例として使われています。
エラー時の対処法は？
LVMの拡張作業では、いくつかの定番エラーがあります。事前にパターンを知っておくだけで、深夜のアラート対応にかかる時間を大幅に短縮できます。
| エラーメッセージ | 主な原因 | 対処法 |
|---|---|---|
| No space left on device | VG内の空き領域が不足 | 新規PVをpvcreate・vgextendで追加する |
| Filesystem is too small | LVは拡張済みだがFS未拡張 | resize2fsまたはxfs_growfsを実行する |
| Device or resource busy | LVがマウント中で操作競合 | umount後に再実行（XFSは原則不要） |
| Invalid argument | コマンドの引数指定ミス | -Lや-lなどオプション構文を再確認する |
| PV is in use | PVが別VGで既に使用中 | pvremoveで初期化してから再登録する |
実際のトラブル事例として多いのが「Filesystem is too small」です。これはlvextendまでは成功しているものの、resize2fsやxfs_growfsの実行を忘れているだけのケースがほとんどとされています。慌てず、lvdisplayで現在のLVサイズを確認し、df -hのサイズと差分があればファイルシステム拡張コマンドを実行すれば、数分以内に解決することが多いです。
もう一つ注意したいのが「PV is in use」エラーです。過去に別のVGに所属していたディスクを使い回そうとした際に発生しやすく、原因を確認しないままpvremoveを実行するとデータを完全に失うリスクがあります。対象ディスクに重要データが残っていないか、必ずバックアップの有無を確認してから作業してください。
状態確認には、pvdisplay・vgdisplay・lvdisplayに加え、vgscan・pvscan・lvscanで全体をスキャンする方法も有効です。lvs -a -o +devicesを使うと、どの物理ディスクがどのLVに割り当てられているかを一覧表示できるため、障害切り分けの初動で重宝します。
運用のコツと注意点
LVMを長期運用する上でのポイントは、拡張のしやすさだけでなく、バックアップとスナップショットの組み合わせにあります。lvcreate –size 10G –snapshot –name snap_lv_app /dev/vg_data/lv_appのようにスナップショットを取得しておけば、アプリケーションの更新前後で状態を保存し、問題発生時に短時間で切り戻せる体制を作れます。スナップショット用の領域は、元LVの変更量に応じて消費されるため、更新頻度が高いデータには元サイズの10〜20%程度を目安に確保しておく運用が一例として挙げられています。
パフォーマンス面では、ストライピング（lvcreate -i 2）やミラーリング（lvcreate –mirror 1）といったオプションも用意されています。ただし、これらはハードウェアRAIDと比較すると管理の柔軟性は高い一方、CPU負荷や構成の複雑さが増す面もあるため、要件に応じた使い分けが必要です。
構成情報のバックアップも忘れずに行います。vgcfgbackup -f /backup/vg_data.cfg vg_dataを定期実行しcronなどでスケジュール化しておけば、メタデータ破損時の復旧手段を確保できます。バックアップ頻度は、構成変更のたびに加え、最低でも週1回程度の定期取得が目安とされています。
セキュリティ面では、LVM関連デバイスへのアクセス権限を必要最小限に絞ることが基本です。ディスク暗号化（LUKSなど）と組み合わせる場合は、LVM層の下にLUKS層を配置する構成が一般的で、この構成であればディスク盗難時のデータ漏えいリスクを抑えられるとされています。障害発生時に慌てないよう、復旧手順書と緊急連絡先を事前に整理しておくことも、運用上重要なポイントのひとつです。
よくある質問
Q1. LVMを使うと通常のパーティションよりディスクI/O性能は落ちますか？
A. 単純な線形割り当て（リニアモード）であれば、性能差はごくわずかとされています。ストライピングを併用する場合はむしろ向上するケースもありますが、構成によって変わるため事前検証が推奨されます。
Q2. 論理ボリュームを縮小することはできますか？
A. ext4はアンマウント状態であれば縮小に対応していますが、XFSは縮小非対応です。縮小が必要な場合は、新規LVを作成してデータを移行する方法が一般的とされています。
Q3. ルートパーティション（/）もLVMで拡張できますか？
A. CentOSやRHELの多くはインストール時点でルートがLVM管理下にあるため、同様の手順で拡張可能です。ただし/bootは通常LVM対象外のため、別途パーティション拡張が必要になる場合があります。
Q4. LVを拡張した後、リブートは必要ですか？
A. 基本的に不要です。lvextendとresize2fs・xfs_growfsはいずれもオンラインで実行でき、システム再起動なしで容量が反映されるとされています。
Q5. VGに追加したPVを後から取り外すことはできますか？
A. pvmoveでデータを他のPVへ退避させた後、vgreduceでVGから除外すれば取り外し可能です。ただし空き容量が十分であることが前提条件になります。
Q6. LVMのスナップショットはバックアップの代わりになりますか？
A. スナップショットは短時間の切り戻し用途には有効ですが、元のディスク自体が故障した場合は失われるため、別ストレージへの本格的なバックアップとは併用が前提とされています。
編集・制作ポリシー：本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なるため、本番環境への適用前には必ず検証環境でのテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。
