Linux LVM パーティション管理ガイド｜柔軟なストレージ運用

Linux LVM パーティション管理ガイド｜柔軟なストレージ運用

現代の PC システムにおいて、ストレージデータの管理は単なる容量確保を超え、システム全体の信頼性とパフォーマンスに直結する重要な要素となっています。特に 2025 年以降、AI 処理や大規模データセットの保存ニーズが高まる中で、固定されたパーティション構成では迅速なリソース割り当てが困難になっています。Linux 環境における LVM（Logical Volume Manager）は、物理ディスクと論理ボリュームを抽象化し、柔軟かつ効率的なストレージ運用を実現する標準的なソリューションです。本ガイドでは、Ubuntu 24.04 LTS や Fedora 41、RHEL 9 など主要な Linux ディストリビューションに対応した LVM の実用的な管理術を、2026 年時点の最新ベストプラクティスに基づいて解説します。

LVM を適切に運用することは、システムメンテナンスの負担を軽減し、ディスク障害時のリスク管理にも寄与しますが、その反面、従来のパーティションテーブル（GPT や MBR）とは異なる仕組みのため、初学者には理解が難しい側面があります。本記事では、物理ボリューム（PV）、ボリュームグループ（VG）、論理ボリューム（LV）という 3 層構造の基礎概念から始まり、実際のセットアップ手順、オンラインでの容量拡張、安全性の高いスナップショット作成、さらには RAID 構成との連携までを網羅的に取り扱います。また、ext4 や XFS といったファイルシステムの違いによる挙動差、あるいは Btrfs のようなネイティブ機能を持つ代替案との比較も行うことで、読者が自身の環境に最適なストレージ設計を選択できるように支援します。

具体的な運用においては、コマンドの理解だけでなく、背後で動作するメタデータの管理や、データ整合性を保つためのロック機構についても深く掘り下げる必要があります。例えば、lvextend コマンドを実行した際にファイルシステムが即座に拡張されるかどうかも、使用するファイルシステムの種類（ext4 か XFS か）によって対応が異なるため、ここで誤るとデータ破損のリスクを招く可能性があります。また、物理ディスクを追加してストレージプールを拡張する際の手順や、スナップショット作成時に必要な容量計算など、実務で直面する具体的な数値シナリオを紹介していきます。

本記事を通じて、読者は LVM の複雑な仕組みを克服し、障害耐性のある柔軟なストレージアーキテクチャを構築できるようになることを目指します。2026 年現在では、NVMe SSD の普及により I/O パフォーマンスが向上していますが、LVM のオーバーヘッドは依然として無視できないため、性能と柔軟性のバランスを取りながらシステムを設計する知見が必要です。以下に示す各セクションにおいて、具体的なコマンドライン操作や設定値の指定方法を詳細に解説いたしますので、実際の Linux サーバーやワークステーションで即座に実践できる内容となっています。

LVM の基本概念と従来のパーティション管理との違い

LVM（Logical Volume Manager）は、Linux カーネル上のデバイスマップパー（dm）サブシステムを利用したストレージ管理手法であり、物理ディスクの断片化された領域を論理的なプールとして統合します。この仕組みにより、ディスクの物理的な接続順序や位置に関係なく、一貫してボリュームにアクセスすることが可能になります。従来のパーティション管理では、1 つのパーティションが特定の物理領域（セクタ範囲）に固定されるため、容量変更にはパーティション削除と再作成というリスクの高い作業が必要でしたが、LVM では論理レベルでのみ管理が行われるため、非破壊的に容量を調整できます。

この 3 層構造は、物理ボリューム（PV）、ボリュームグループ（VG）、論理ボリューム（LV）で構成されており、それぞれがデータの保持単位となっています。まず PV は、pvcreate コマンドによって LVM メタデータを含むディスクまたはパーティションを指します。これは LVM の管理下に置かれた「素材」となる領域です。次に VG は、複数の PV を結合して作成されたストレージプールであり、ここから LV へ容量が割り当てられます。最後は LV で、これがファイルシステムとしてマウントされ、ユーザーが直接データを保存する最終的なボリュームとなります。この抽象化レイヤーがあるおかげで、ディスクの物理的交換や増設をシステム停止なしで行うことが可能になります。

従来のパーティション管理と比較した場合、LVM の最大のメリットは柔軟性と拡張性ですが、いくつかのデメリットも認識しておく必要があります。以下に主な特徴を比較表としてまとめました。

LVM の構成要素であるメタデータは、通常ディスクの先頭と末尾に保存され、これにより特定のセクタに損傷があっても情報復元を試みることができます。ただし、この仕組みが LVM 特有の複雑性を生んでおり、初心者にとって「どこにメタデータがあるのか」を把握するのは容易ではありません。また、LVM を使用するとディスクのシーク動作パターンが変わるため、機械式 HDD の場合、従来のパーティション配置とは異なる I/O パフォーマンス特性を示すことがあります。特に 2026 年時点では NVMe SSD が主流となっていますが、大容量の SATA HDD をアーカイブ用に使用する場合でも LVM の管理機能は依然として有効です。

さらに、LVM のメタデータ構造にはバージョンがあり、LVM2 2.03.x 以降ではメタデータの冗長化やロック機構が強化されています。これにより、複数ノードで共有ストレージを利用するクラスタ環境における整合性維持が容易になっていますが、単一サーバーでの運用においても、vgcfgbackup コマンドによる定期的なバックアップが推奨されます。もし LVM メタデータが破損した場合、従来のパーティションテーブル修復ツールでは復旧できず、専用の LVM ツール（vgck, vgcfgrestore）を使用する必要があります。この点からも、LVM を導入する際にはメタデータの管理手順を事前に確立しておくことが必須となります。

LVM の初期セットアップとボリューム作成手順

Linux システムへの LVM 環境の構築は、インストール時の選択肢に任せることもできますが、カスタマイズした構成を行う場合は手動での設定が必要です。Ubuntu 24.04 LTS や Fedora 41 のインストーラーでは、ディスクレイアウトの設定画面で「LVM」というオプションが提供されており、これを選択すると自動的に PV と VG が作成されます。しかし、RHEL 9 や Arch Linux などの環境では、インストール後に lvm2 パッケージを明示的にインストールし、コマンドラインから構成するケースが多くなります。ここでは、 freshly installed なシステムに新規で LVM を構築する手順を、実用的なシナリオに基づいて解説します。

まず、LVM の前提となる物理ボリューム（PV）の作成を行います。これは /dev/sdb1 などの既存パーティションまたはディスク全体に対して実行します。pvcreate コマンドを使用し、対象デバイスに LVM メタデータを書き込みます。この際、オプションとして -ff （force）を指定することで、既に存在する不明なメタデータを上書きして作成できますが、誤って重要なデータを消去しないよう注意が必要です。また、-y オプションを付与すると確認プロンプトを自動で肯定し、バッチ処理をスムーズに進めることができます。2026 年現在、大型の NVMe SSD ではシークアンス速度が高いため、メタデータ書き込みによる I/O スターブはほとんど発生しません。

sudo pvcreate -ff /dev/sdb1 /dev/sdc1

次に、作成した PV を結合してボリュームグループ（VG）を作成します。vgcreate コマンドにより、PV の合計容量をプールとして利用可能にします。VG 名は任意の名前（例：data_vg）を指定しますが、システム内で一意である必要があります。この VG は、その後の論理ボリューム（LV）の母体となるため、名前には「用途」や「場所」を含めるなど、運用上のルールを設けるのがベストプラクティスです。VG 作成時に物理拡張（PE）サイズを指定することも可能ですが、デフォルト値（通常 4MB）が多くのケースで最適化されています。

sudo vgcreate data_vg /dev/sdb1 /dev/sdc1

最後に、VG から論理ボリューム（LV）を作成し、ファイルシステムを適用します。lvcreate コマンドを使用し、サイズ指定（-L オプション）と名前指定（-n オプション）を行います。例えば、100GB の論理ボリュームを root_lv として作成する場合の命令は以下のようになります。

sudo lvcreate -L 100G -n root_lv data_vg

この LV はまだファイルシステムを持っていないため、mkfs.ext4 または mkfs.xfs を使用してフォーマットする必要があります。ここで注意すべきは、使用するファイルシステムの選択です。ext4 は汎用性が高く、Linux 標準として広くサポートされていますが、XFS は大規模データや高速な I/O に特化しており、2026 年のサーバー環境では XFS がデフォルトとなるケースが増えています。以下に主要ディストリビューションにおける LVM デフォルト設定と推奨コマンドの差異をまとめました。

ファイルシステム作成後は、/dev/mapper/data_vg-root_lv または /dev/data_vg/root_lv という経路でアクセスできるようになります。このパスを /etc/fstab に記述することで、システム起動時に自動マウントされます。ただし、LVM のパス名はデバイス名の論理名に依存するため、ハードウェアの物理名（sdb1 など）とは異なるため、システム再起動後も一貫性を保つことができます。

セットアップ完了後には、pvs, vgs, lvs コマンドを使用して状態を確認するのが習慣です。これらのコマンドは LVM のメタデータを読み取り、現在の構成を可視化します。特に pvs -o +pv_used,pv_free オプションを使用すると、各物理ボリュームの使用中容量と残量が即座に確認できます。2026 年時点では、lsblk --inverse コマンドも併用して階層構造を確認することが推奨されており、LVM の論理デバイスがどの物理ディスク上に存在するかを追跡しやすくしています。

ボリュームの拡張手順とストレージプールの運用

LVM の最大の利点である「オンラインでの容量拡張」について解説します。システム稼働中にディスク容量不足が発生した場合、従来のパーティション方式ではファイルシステムを縮小・削除・再作成するリスクの高い作業が必要でしたが、LVM では停止時間を最小限に抑えながら対応可能です。ただし、拡張可能な範囲は論理ボリューム（LV）とファイルシステムの種類によって制約があり、これらを正しく理解しておく必要があります。

まず、既存の LV に対して容量を追加する場合の手順です。lvextend コマンドを使用し、-L オプションで新しいサイズを指定します。あるいは、+10G のように増加分だけを指定することも可能です。例えば、現在の 100GB の LV を 50GB 拡張したい場合は lvextend -L +50G /dev/data_vg/root_lv と入力します。ここで重要なのは、このコマンドだけではファイルシステム自体は拡張されない点です。LV は論理アドレス空間が増えただけで、マウント先のファイルシステムがその領域を認識しないため、データ書き込み時にエラーが発生します。

ファイルシステムの拡張には、ext4 用と XFS 用で異なるツールを使用する必要があります。ext4 を使用している場合は resize2fs コマンドを実行し、LV のデバイスパスを指定することで同期してサイズ拡大を行います。このコマンドはオンライン（マウント状態）でも実行可能ですが、安全性確保のためには余裕を持って行うことが推奨されます。

sudo resize2fs /dev/data_vg/root_lv

一方、XFS を使用している場合は xfs_growfs コマンドを使用します。XFS は ext4 と異なり、ファイルシステム拡張時に論理ボリュームのデバイスパスではなく、マウントポイント（ディレクトリ）を指定する必要があります。これは XFS の内部構造がブロックアロケーションに依存しており、マウント状態でのメタデータ更新を前提としているためです。

sudo xfs_growfs /mnt/data_mount_point

もし単一の LV 内の容量不足に対して、VG に未割り当ての容量がない場合は、VG 自体の拡張が必要です。これは物理ディスクを追加して PV を作成し、それを VG に追加することで実現します。vgextend data_vg /dev/sdd1 のように実行し、新しい PV をプールに統合すると、LV が使用する余地が生まれます。このプロセスにより、ストレージプールの総容量が増加し、既存の LV や新規作成する LV に対して利用可能になります。

2026 年現在では、NVMe SSD の高速性を利用してキャッシュボリュームを LVM キャッシュとして構成する手法も一般的です。LVM Cache を使用すると、頻繁にアクセスされるデータを HDD 上の LV と SSD 上のキャッシュ LV に分けて管理し、パフォーマンスを向上させることができます。この場合、拡張手順は通常の LV 拡張と異なり、キャッシュプールへの追加容量指定が必要になります。

以下は、ストレージプールの拡張プロセスにおける重要なチェックポイントのリストです。

• 事前確認: vgs コマンドで VG の未割り当て容量（VFree）を確認する。
• ファイルシステム種別: ext4 か XFS かを特定し、適切な拡張コマンドを選択する。
• ロック解除: 拡張前にデータ整合性を保つため、他のプロセスによる書き込みを止める（可能な場合）。
• メタデータ更新: 拡張後に vgcfgbackup を実行し、新しい構成をバックアップする。
• 再起動テスト: 設定変更後、一度マウント解除・再マウントして正常動作を確認する。

また、VG の容量が不足している場合でも、lvconvert --type raid1 のように RAID モードに切り替えることで、既存の PV をミラーリングとして再利用し耐性を高めることができます。ただし、この操作には元の LV のコピーに時間がかかるため、夜間などメンテナンスウィンドウで行うことが推奨されます。

ボリューム縮小手順とリスク管理について

LVM 環境で最も注意が必要な作業が「ボリュームの縮小」です。拡張はオンラインで安全に行えますが、縮小はデータの破損やメタデータの不整合を引き起こす可能性が高く、慎重な手順と事前バックアップが必須となります。特に XFS ファイルシステムは設計上、容量を小さくする機能を持っていないため、縮小を試みると即座にエラーが発生し、作業が中断されます。

ext4 ファイルシステムの場合、resize2fs コマンドを使用して縮小可能です。ただし、これはオンラインではリスクが高いため、原則としてアンマウント（オフライン）状態で行う必要があります。手順としては、まずファイルを退避させ、システムをリブートしてシングルユーザーモードまたはライブメディアから起動し、ファイルシステムを確認した上で縮小コマンドを実行します。

sudo umount /mnt/data_mount_point
sudo e2fsck -f /dev/data_vg/root_lv
sudo resize2fs /dev/data_vg/root_lv 50G

この際、resize2fs はファイルシステムのブロックサイズを確認し、指定したサイズがデータ保持に必要な最小容量より小さい場合は自動でエラーを返します。しかし、ファイルシステム内の断片化状況やメタデータの位置によっては、理論上の最小値より多くの領域が必要になるケースがあり、計算誤りによる破損リスクがあります。

XFS ファイルシステムの縮小は xfs_growfs の逆操作のように思われますが、実は xfs_admin -d などのコマンドで物理容量を調整することはできません。2026 年時点でも XFS の仕様上、サイズ縮小機能は実装されていません。これは、XFS がメタデータをファイルシステムの末尾に配置し、拡張時にのみデータを書き込む設計のためです。縮小を行うには、一旦データを別のストレージへ移動させ、LV を再作成する手間が必要です。

したがって、縮小を伴うリサイズ計画を立てる際は、以下のリスク管理手順を厳守してください。

1. 完全バックアップ: dd コマンドまたは rsync でデータ全体のイメージを作成する。
2. ファイルシステムチェック: fsck や xfs_repair を事前実行して破損がないか確認する。
3. 最小容量計算: 使用中のデータ量が LV のサイズより十分小さいことを確認する（余裕は 20% 推奨）。
4. 作業ウィンドウ: システム停止を伴うため、ユーザーへの通知とメンテナンス時間を確保する。
5. 代替手段検討: 縮小できない場合は、LV を削除して新しい LV を作成し、データを移行する。

データ移行による再構築の手順は以下の通りです。まず、容量の余裕がある別の LV または外部ストレージを用意します。その後、元 LV のファイルをすべてコピーし、元の LV を削除（lvremove）した後、新しいサイズで再度作成します。このプロセスは一見単純ですが、膨大なデータ量の場合には数時間かかる可能性があり、ネットワーク転送速度やディスク I/O パフォーマンスがボトルネックになることがあります。

また、LVM のメタデータ領域自体も縮小できるかどうか検討する必要があります。pvresize コマンドを使用することで、物理ボリュームのサイズを調整できますが、これも同様にバックアップと慎重な操作が必要です。2026 年時点では、Btrfs ファイルシステムのように、ネイティブでスナップショットとリサイズ機能を備えた選択肢も増えています。しかし、既存の LVM + ext4/XFS 環境を変更するコストを考慮すると、縮小は最後の手段として位置づけるのが無難です。

スナップショット機能によるデータ保護と COW 方式

LVM のスナップショット機能は、システムアップデートや設定変更前のセーフティネットとして極めて有効なツールです。これは「コピーオンライト（COW: Copy-On-Write）」という仕組みを採用しており、元のデータの全コピーを行うのではなく、変更されたブロックのみを新しい領域に記録します。この方式により、数十 GB のデータでも数 MB の容量のスナップショットを作成することが可能で、ストレージ効率と回復速度の両面で優れています。

スナップショット作成は lvcreate コマンドに --snapshot オプションを追加することで実行できます。例えば、/dev/data_vg/root_lv に対して 10GB のスナップショットを作成する場合は以下のようになります。

sudo lvcreate -L 10G --name root_snap --snapshot /dev/data_vg/root_lv

作成されたスナップショットは /dev/data_vg/root_snap という経路でアクセス可能ですが、通常はマウントして直接読み書きを行うことはできません。これは COW 方式の特性上、元のボリューム（オリジナル）とスナップショットが同じデータブロックを参照しているためです。もしスナップショット上でデータを書き込むと、そのブロックは自動的に新しい領域にコピーされ、元データとの差分管理が行われます。

この機能を利用した典型的なユースケースは、システムアップデート前の状態保存です。例えば、パッケージ管理者（apt や dnf）による OS 更新を行う前に LVM スナップショットを作成しておけば、更新後にシステムが起動しなくなった場合でも、スナップショットに戻して復旧が可能です。2026 年現在では、自動バックアップツールとの連携も強化されており、lvm-snapshot ユーティリティが標準パッケージに含まれるケースもあります。

ただし、COW 方式には性能上の制約があります。スナップショット作成直後は元のデータへのアクセス効率は維持されますが、頻繁に書き込みが行われるとスナップショット領域（メタデータ）が飽和し、「スナップショットの完全な破損」を引き起こす可能性があります。これを防ぐため、スナップショット作成時に十分な容量を確保することが重要です。また、パフォーマンス低下を避けるため、スナップショットは読み取り専用として使用し、書き込みが必要な場合はマウント後にコピーを作成するか、別ボリュームへ移行するのがベストプラクティスです。

スナップショットの管理と削除には以下の手順が用いられます。

• 状態確認: lvs -o +snap_used コマンドでスナップショット領域の使用率を確認する。
• 統合処理: 問題がない場合、スナップショットを元ボリュームに統合（merge）する。
• 削除手順: 不要になった場合は lvremove /dev/data_vg/root_snap で即座に削除可能。
• ロック解除: 削除前に必ずアンマウントし、プロセスが終了していることを確認する。

以下は LVM スナップショットと Btrfs スナップショットの比較表です。両者ともスナップショット機能を提供しますが、実装方式に明確な違いがあります。

LVM のスナップショットは、元ボリュームが破損すると参照先を失うため、重要なデータに対しては外部へのエクスポート（dd や rsync）も併用するのが安全です。また、2026 年時点では、クラウドストレージ連携による自動バックアップ戦略との組み合わせも推奨されており、オンプレミス LVM スナップショットを「ローカルフェイルオーバー」として位置づける運用が増えています。

RAID との連携構成とハイブリッドストレージ設計

LVM は単独でのボリューム管理だけでなく、RAID（Redundant Array of Independent Disks）機能とも親和性が高く、データ保護とパフォーマンス向上を両立させる構成が可能です。Linux における RAID 構成には、主に「mdadm」によるカーネルレベルのソフトウェア RAID と、「dm-raid」と呼ばれる LVM レベルでの RAID の 2 つのアプローチがあります。

mdadm を利用する場合、まず物理ディスクを md デバイス（例：/dev/md0）として RAID1 や RAID5 に構成し、その上に LVM の PV を作成します。この方式は OS 起動時にも RAID が認識されており、LVM メタデータ保護の観点からは極めて堅牢です。特に 2026 年時点では NVMe SSD の高速性を活かした RAID0（ストライピング）構成が、データベースや AI トレーニング用ストレージで広く採用されています。

sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1
sudo pvcreate /dev/md0
sudo vgextend data_vg /dev/md0

一方、LVM 自体の機能である dm-raid を利用する方法もあります。これは物理ディスクを直接使用し、LV の作成時に RAID モード（mirror, raid4, raid5, raid6）を指定して構築します。mdadm との違いは、RAID メタデータが LVM メタデータと統合される点です。これにより、管理コマンドの統一性が高まりますが、LVM の依存度が高まるため、LVM コンポーネントに障害が発生すると RAID 全体にも影響を及ぼす可能性があります。

以下は、RAID 構成における主要なモードとその用途を示した表です。

LVM + RAID を組み合わせたハイブリッド構成では、パフォーマンスが必要な LV は RAID0 で高速化し、重要なデータは RAID1 に配置するなど、用途に応じた使い分けが可能です。また、2026 年現在では、ZFS や Btrfs のような次世代ファイルシステムが LVM の代わりに使用されるケースも増えていますが、既存の Linux サーバー資産を維持する場合、LVM と mdadm の組み合わせは依然として標準的な選択肢です。

さらに、LVM のキャッシュ機能（lvconvert --type cache-pool）を RAID 構成と併用することで、HDD 上の RAID5/RAID6 構成でも SSD キャッシュにより I/O レイテンシを改善できます。これは、コストパフォーマンスを重視する環境において非常に有効です。ただし、キャッシュ設定には SSD の寿命管理（TRIM 対応など）も考慮する必要があり、LVM2 2.03.x 以降ではキャッシュの自動最適化機能が提供されています。

よくある質問（FAQ）

Q1: LVM を使用していてもディスクが故障したらデータは守られますか？ A1: LVM 単体では RAID やミラーリング機能を備えていないため、物理ディスクの故障によりデータ喪失が発生するリスクがあります。データ保護には dm-raid モードの使用や mdadm との併用、あるいは定期的なバックアップが必須となります。LVM は「容量管理」のための技術であり、「冗長化」は別途実装する必要があります。

Q2: スナップショットを作成するとシステムに負荷がかかりますか？ A2: 作成直後は COW メタデータの更新により若干の I/O オーバーヘッドが発生しますが、通常の使用では体感レベルで影響はありません。ただし、大量の書き込みが行われるとスナップショット領域が飽和し、元ボリュームへの書き込み阻止（full snapshot）が発生する可能性があるため、容量管理を徹底してください。

Q3: Ubuntu のインストーラーで LVM を選択しましたが、コマンドが使えません。 A3: インストール時に自動設定された場合は lvm2 パッケージがインストール済みです。もしコマンドが見つからない場合は sudo apt install lvm2 でパッケージを追加してください。また、Ubuntu 24.04 では Btrfs がデフォルトのファイルシステムとして選べるため、LVM の設定とは別に確認が必要です。

Q4: XFS ファイルシステムの縮小は絶対にできないのですか？ A4: 現状の仕様では xfs_growfs の逆操作（縮小）はサポートされていません。これはメタデータの配置構造上の問題によるもので、将来的なアップデートで追加される可能性は低いです。縮小が必要な場合は、データを移行して LV を再作成するしかありません。

Q5: LVM メタデータが破損した場合の復旧手順を教えてください。 A5: まず vgck コマンドでメタデータの整合性を確認します。問題がある場合、vgcfgrestore コマンドを使用して /etc/lvm/backup に保存されたバックアップファイルから復元を試みます。それでも復旧できない場合は vgreduce --removemeta を使用して強制リセットを行う必要がありますが、これはデータ消失のリスクを伴います。

Q6: LVM の物理拡張（PE）サイズを変更できますか？ A6: VG 作成時に -s オプションで指定可能です（例：-s 1M）。ただし、一度設定した PE サイズは後から変更できません。LVM2 2.03.x 以降ではデフォルトの 4MB が多くの環境で最適化されているため、特別な理由がない限り変更しないのが推奨されます。

Q7: LVM と ZFS を併用することは可能ですか？ A7: 理論上は可能ですが、非推奨です。ZFS は独自のブロック管理を行うため、LVM の抽象化レイヤーを介するとパフォーマンス低下やデータ整合性の問題が発生する可能性があります。どちらか一方を採用し、ストレージ設計の基盤として統一するのが望ましいです。

Q8: LVM スナップショットと Btrfs サブボリュームの違いは？ A8: LVM スナップショットは元ボリュームに依存し、削除不可です。Btrfs は独立したサブボリュームとして扱え、コピーやマウントが柔軟に行えます。LVM が OS レベルの管理に特化しているのに対し、Btrfs はファイルシステムレベルで高度な機能を提供します。

Q9: 仮想環境（KVM/QEMU）内でも LVM を使用できますか？ A9: はい、可能です。ただし、ホスト側がブロックデバイスとして LVM LV を提供する場合、ゲスト OS 内部でのパーティション管理は必要なくなります。これはストレージの動的割り当てを可能にし、リソース効率を高めます。

Q10: LVM の設定変更後、再起動しても反映されますか？ A10: lvcreate や vgextend での変更は永続的ですが、ファイルシステムのマウント情報は /etc/fstab に記載する必要があります。LVM 自体の構成情報はメタデータとして保存されるため、再起動後も自動的に復元されますが、マウント設定忘れに注意してください。

まとめ

本記事では、Linux LVM（Logical Volume Manager）を使った柔軟なパーティション管理について、2026 年時点の最新情報を反映して詳細に解説しました。LVM は従来の固定パーティション管理の欠点を補完し、ディスク容量の動的拡張やスナップショット機能により、システム運用の信頼性を大幅に向上させる技術です。

記事全体を総括する主なポイントは以下の通りです。

• 3 層構造の理解: PV（物理ボリューム）、VG（ボリュームグループ）、LV（論理ボリューム）の階層を理解し、それぞれの役割を明確にする。
• コマンド運用: pvcreate, vgcreate, lvcreate の基本手順と、Ubuntu/Fedora/RHEL における設定の違いを把握する。
• 拡張と縮小: 容量変更はオンラインで可能だが、XFS は縮小不可であるため注意が必要であり、事前バックアップが必須である。
• スナップショット活用: COW 方式による高速なスナップショット作成と管理により、アップデート前のセーフティネットとして機能させる。
• RAID 連携: LVM と mdadm の併用や dm-raid モードを用いて、データ冗長性とパフォーマンスのバランスを取る。

LVM を適切に設計・運用することは、システム管理者としてのスキル向上だけでなく、2026 年以降の複雑化するストレージ環境においても安定したサービス提供を可能にする基盤となります。各セクションで解説した具体的なコマンドや設定値を実際の環境で試し、自分のワークフローに合った最適な構成を見つけてください。安全で柔軟なストレージ運用の実現に向けて、本ガイドが参考になれば幸いです。