繰り返すディスク容量問題
VPSを立ち上げ、/varに20GBを割り当てる。そして半年後、ログとデータベースがその領域をぴったり埋め尽くす。従来の対処法は？レスキューモードで起動し、fdiskでパーティションをリサイズして、何も壊れないよう祈るだけ。サーバー管理を始めた最初の1年でこのサイクルを2回経験し、3年間で10台以上のサーバーを管理してきたが、毎回うんざりさせられた。
最終的に学んだのは、セットアップ時のディスクパーティション決定は必ずいつか間違いになるということだ。多く割り当てれば無駄が生まれ、少なく割り当てれば後で慌てることになる。LVM（論理ボリュームマネージャー）はそのサイクルを断ち切るために存在する。物理ディスクのレイアウトとOSが認識する論理パーティションを分離することで、後から本当の柔軟性が生まれる。
基本概念：LVMの仕組み
LVMは物理ディスクとマウントポイントの間に薄い抽象レイヤーを追加する。モデル全体を3つの用語で説明できる：
物理ボリューム（PV）
PVはLVMに渡す生のディスクまたはパーティションだ。/dev/sdb、/dev/sdc1、あるいはRAIDアレイでもよい。LVMはPVに独自のメタデータを書き込み、利用可能なリソースを追跡する。
ボリュームグループ（VG）
VGはストレージプールだと考えるといい。複数のPVをVGに追加すると、LVMはその合計容量を1つの大きく柔軟なバケツとして扱う。後でプールの容量が足りなくなったら？ディスクを追加するだけ——再起動もデータ移行も不要、余計な手間なし。
論理ボリューム（LV）
LVはOSが実際にマウントするものだ。VGプールから切り出して作成する。/varに10GB必要？10GBのLVを作成し、フォーマットしてマウントするだけ。来月15GBが必要になったら？コマンド1つで拡張できる。ファイルシステムはLVの上に乗っており、下の物理ディスクを気にする必要はない。
視覚的には、スタックは以下のようになる：
物理ディスク → 物理ボリューム → ボリュームグループ → 論理ボリューム → ファイルシステム
/dev/sdb → PV → pool_vg → lv_var (10G) → ext4（/var）
/dev/sdc → PV → → lv_home (20G) → xfs（/home）実践：LVMをゼロからセットアップする
ステップ1：LVMツールのインストール
Debian/Ubuntuの場合：
sudo apt update && sudo apt install lvm2 -yRHEL/AlmaLinux/Rockyの場合：
sudo dnf install lvm2 -yステップ2：物理ボリュームの作成
2つの新しいディスク（/dev/sdbと/dev/sdc）を追加済みとして：
sudo pvcreate /dev/sdb /dev/sdc
sudo pvs # 確認pvsの出力には両方のディスク、サイズ、所属するVG（今は空欄）が表示される。
ステップ3：ボリュームグループの作成
sudo vgcreate data_vg /dev/sdb /dev/sdc
sudo vgs # 確認完了。data_vgが両ディスクの合計容量を1つのプールとして管理するようになった。
ステップ4：論理ボリュームの作成
# /var用に15GBのLVを作成
sudo lvcreate -L 15G -n lv_var data_vg
# /home用に25GBのLVを作成
sudo lvcreate -L 25G -n lv_home data_vg
# 残りの空き領域をデータボリュームに使用
sudo lvcreate -l 100%FREE -n lv_data data_vg
sudo lvs # 3つすべてを確認ステップ5：フォーマットとマウント
sudo mkfs.ext4 /dev/data_vg/lv_var
sudo mkfs.ext4 /dev/data_vg/lv_home
sudo mkfs.xfs /dev/data_vg/lv_data
sudo mkdir -p /var/lvm_var /home/lvm_home /data
sudo mount /dev/data_vg/lv_var /var/lvm_var
sudo mount /dev/data_vg/lv_home /home/lvm_home
sudo mount /dev/data_vg/lv_data /data再起動後も永続的にマウントするために、/etc/fstabに以下の行を追加する：
/dev/data_vg/lv_var /var/lvm_var ext4 defaults 0 2
/dev/data_vg/lv_home /home/lvm_home ext4 defaults 0 2
/dev/data_vg/lv_data /data xfs defaults 0 2本当に助かる操作
論理ボリュームの拡張（ライブ）
このコマンドこそがLVMを使う最大の理由だ。マウントして使用中のままlv_varを5GB拡張する：
# LVを拡張
sudo lvextend -L +5G /dev/data_vg/lv_var
# ファイルシステムを新しい領域に対応させてリサイズ（ext4）
sudo resize2fs /dev/data_vg/lv_var
# XFSの場合（拡張のみ可能、縮小は不可）
sudo xfs_growfs /var/lvm_varダウンタイムなし。再起動なし。ファイルシステムはその間ずっと稼働中だ。
既存のVGへの新しいディスクの追加
プールの容量が足りなくなり、新しいディスク（/dev/sdd）を接続した場合：
sudo pvcreate /dev/sdd
sudo vgextend data_vg /dev/sdd
sudo vgs # 新しい合計サイズを確認その容量はすぐにLV拡張に使える。本番サーバーで実際に計測したことがあるが、最初から最後まで30秒以内だった。
論理ボリュームの縮小
縮小はリスクが高く、より慎重な操作が必要だ。必ず先にアンマウントし、必ずデータをバックアップする。XFSはまったく縮小できない——これはext4専用の操作だ。
# まずアンマウント
sudo umount /var/lvm_var
# ファイルシステムのチェック
sudo e2fsck -f /dev/data_vg/lv_var
# LVを縮小する前にファイルシステムを縮小
sudo resize2fs /dev/data_vg/lv_var 10G
# その後LVを縮小
sudo lvreduce -L 10G /dev/data_vg/lv_var
# 再マウント
sudo mount /dev/data_vg/lv_var /var/lvm_var鉄則：ファイルシステムを目標のLVサイズより小さくリサイズしてから、LVを縮小すること。順序を逆にするとデータが壊れる。本番環境で実施する前に、捨ててもいいVMで練習すること——夜中の2時に開発サーバーでその失敗を犯したが、十分痛い経験だった。
バックアップ用LVMスナップショット
スナップショットはLVの特定時点のコピーを取得する。リスクの高い操作の直前——大規模なパッケージアップグレード、設定の大幅変更、ロールバックしたくなるかもしれない操作——に最も役立つ：
# lv_varの2GBスナップショットを作成
sudo lvcreate -L 2G -s -n lv_var_snap /dev/data_vg/lv_var
# スナップショットを読み取り専用でマウント
sudo mount -o ro /dev/data_vg/lv_var_snap /mnt/snapshot
# 完了したらスナップショットを削除
sudo umount /mnt/snapshot
sudo lvremove /dev/data_vg/lv_var_snapスナップショットはコピーオンライトを使用する——作成後に変更されたブロックだけがスナップショットボリュームに書き込まれ、完全なコピーは作成しない。短命に保つべきだ。スナップショットが割り当て済み領域を超えると、LVMは自動的に無効としてマークしてオフにする。リカバリーポイントを失い、割り当て済み領域も無駄になる。書き込みが活発なLVのスナップショットには、そのサイズの少なくとも15〜20%を割り当てること。
便利な確認コマンド
LVMのセットアップを確認する際に定期的に実行する価値のあるコマンド：
pvdisplay— 物理ボリュームの詳細情報vgdisplay— VGサイズ、空き領域、PE数lvdisplay— LVのパス、サイズ、スナップショットのステータスlsblk— LVを含むすべてのブロックデバイスのツリー表示df -h— ファイルシステムの使用量（マウント）
# LVM全体のクイックサマリー
sudo pvs && sudo vgs && sudo lvs実践でのLVM：本当に重要なこと
LVMは従来のディスクパーティション管理の核心的な問題を解決する：セットアップ時に正確な見積もりをしなくてもよくなる。妥当な割り当てから始め、実際の使用パターンが明らかになるにつれてリサイズする——本番のダウンタイムなしに。
覚えておく価値のあるコマンドが3つある：ライブリサイズにはlvextend + resize2fs、プールへのディスク追加にはpvcreate + vgextend、リスクの高い変更前のスナップショットにはlvcreate -s。この3つで実際のLVM作業の90%をカバーできる。
新しいサーバーを立ち上げる際は、リサイズすることはないと確信していても、最初からLVMで構築しよう。セットアップコストはほぼゼロ。いざ必要になったときのメリットは計り知れない。
