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

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

さらに、LVM のメタデータ構造にはバージョンがあり、LVM2 2.03.x 以降ではメタデータの冗長化やロック機構が強化されています。これにより、複数ノードで共有ストレージを利用するクラスタ環境における整合性維持が容易になっていますが、単一サーバーでの運用においても、vgcfgbackup コマンドによる定期的なバックアップが推奨されます。もし LVM メタデータが破損した場合、従来のパーティションテーブル修復ツールでは復旧できず、専用の LVM ツール（vgck, vgcfgrestore）を使用する必要があります。この点からも、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 の基本手順と、U[bun](/glossary/bun-runtime)tu/[Fedora](/glossary/dora-fine-tuning)/RHEL における設定の違いを把握する。
• 拡張と縮小: 容量変更はオンラインで可能だが、XFS は縮小不可であるため注意が必要であり、事前バックアップが必須である。
• スナップショット活用: COW 方式による高速なスナップショット作成と管理により、アップデート前のセーフティネットとして機能させる。
• RAID 連携: LVM と mdadm の併用や dm-raid モードを用いて、データ冗長性とパフォーマンスのバランスを取る。

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

【2026年】マルチブートOS管理ガイド｜Windows・Linux・macOSを1台で使い分ける

1台のPCで複数OSをマルチブート管理する方法。パーティション設計、ブートローダー設定、データ共有のコツを解説。