LVMスナップショットを更新作業の安全網にする｜作成・差分確認・削除の運用サイクル

なぜLVMスナップショットが「更新前の安全網」になるのか

パッケージの大規模更新やカーネルのアップグレードは、事前検証を重ねた場合でも「本番では想定外の挙動をする」リスクをゼロにはできません。フルバックアップを取る時間も手段もない短い作業窓で、とにかく「即座に戻せる状態」を確保したい──そのニーズに応えるのがLVMスナップショットです。

LVMのスナップショットはCopy-on-Write（CoW）機構で動作します。スナップショット作成直後はディスクをほぼ消費せず、元のLV（論理ボリューム）に書き込みが発生した瞬間だけ、変更前ブロックをスナップショット領域へコピーします。つまり「更新作業中に変化したブロックだけ」を保持する差分保存方式です。作業が成功すればスナップショットを削除するだけ。失敗すればスナップショットを元に戻す──このサイクルを運用の標準手順として組み込むことが、LVMスナップショット活用の本質です。

ただし、スナップショットは完全なバックアップではありません。LV自体が存在するディスクが物理的に壊れれば、スナップショットも失われます。「作業の切り戻し手段」と「障害時の復旧手段」は目的が異なり、前者にスナップショット、後者に別途バックアップを使い分けることが前提です。

スナップショットの作成手順

作業対象のLVを確認するところから始めます。

lvs
# または詳細表示
lvdisplay /dev/vg0/lv_root

対象LVのサイズと現在の使用量を把握した上で、スナップショットを作成します。サイズの目安は「作業中に発生する書き込み総量」です。パッケージ更新であれば更新後ファイルサイズの1.5〜2倍を見ておくと安心です。一般的なdnf upgradeやapt full-upgradeであれば5〜10 GB前後で足りることが多いですが、カーネル再構築やDBのVACUUMを伴う場合はより大きな領域が必要です。

# 従来型（シックプロビジョニング）スナップショットの作成
lvcreate -L 8G -s -n lv_root_snap /dev/vg0/lv_root

オプションの意味は以下のとおりです。

• -L 8G：スナップショット用に確保するCoW領域のサイズ
• -s：スナップショットモードで作成
• -n lv_root_snap：スナップショットLVの名前
• 最後の引数：スナップショット対象の元LV

作成直後にマウント確認をしておくと、後続のロールバック操作でつまずくリスクが減ります。スナップショットLVは読み取り専用でマウントして内容を確認するだけでよく、通常は常時マウントしておく必要はありません。

mkdir -p /mnt/snap_check
mount -o ro /dev/vg0/lv_root_snap /mnt/snap_check
ls /mnt/snap_check
umount /mnt/snap_check

マウントして内容が正しく見えれば、スナップショットの取得は成功です。この時点で更新作業を開始します。

差分の確認──スナップショット消費量をモニタリングする

更新作業中や終了後に、スナップショット領域の消費状況を確認することは重要です。領域が満杯になるとスナップショットが無効化（invalidate）され、ロールバックできなくなります。

lvs -o lv_name,lv_size,data_percent,snap_percent vg0

snap_percent列がスナップショット領域の使用率を示します。70〜80%を超えてきたら残りの作業量を見直すか、スナップショットを拡張します。

# スナップショット領域を動的に拡張（従来型LVの場合）
lvextend -L +4G /dev/vg0/lv_root_snap

より詳細なCoWブロック状況を確認したい場合はdmsetup statusが有効です。

dmsetup status vg0-lv_root_snap

出力の数値はブロック単位で、現在消費済みブロック数と全体ブロック数が確認できます。lvsのパーセント表示と合わせて確認することで、残りの余裕をより正確に把握できます。

更新が完了し問題がないと判断した段階で、スナップショットの消費量は「今回の更新で実際に変化したデータ量」の実績値になっています。次回以降の作業でスナップショットサイズを見積もる際の参考値として記録しておくと、チーム内のナレッジになります。

ロールバック──問題発生時の切り戻し手順

更新後にサービスが異常終了する、起動プロセスが途中で止まる、といった問題が発生した場合、LVMスナップショットでのロールバックは2通りの方法があります。

方法1：lvconvert –merge によるマージロールバック

最もシンプルな方法です。元LVをアンマウントし、スナップショットをマージすることで元の状態に戻します。

# 対象LVをアンマウント（ルートLVの場合は後述の注意）
umount /mnt/target

# スナップショットをマージ
lvconvert --merge /dev/vg0/lv_root_snap

マージ後は対象LVを再マウントするか、ルートLVの場合はシステムを再起動します。マージはアクティブなLVに対して即時実行されない場合があり、その場合はシステム再起動時に自動的に適用されます。

方法2：ルートLVのロールバック（シングルユーザーモード利用）

対象がルートLVの場合、マウント中のままではlvconvert --mergeがすぐには反映されません。GRUBメニューからシングルユーザーモード（rescue.target）で起動し、スナップショットのマージを確認した上で再起動する手順が安全です。

# シングルユーザーモードでの確認（マージ予約済みであることを確認）
lvs -o lv_name,lv_attr,origin vg0

# 再起動でマージが適用される
reboot

再起動後、スナップショットLVは自動的に削除されます。元LVは更新前の状態に戻っているため、サービスが再び正常起動することを確認します。

スナップショットの削除と運用サイクルの完結

更新が成功し、一定の動作確認期間（一般的には数時間〜翌営業日まで）を経過したら、スナップショットを削除してサイクルを完結させます。スナップショットが存在し続ける間は、元LVへの書き込みのたびにCoW処理が走るため、I/Oオーバーヘッドが継続します。確認が終わったら速やかに削除することが運用の鉄則です。

lvremove /dev/vg0/lv_root_snap

削除後にlvsで対象スナップショットが消えていることを確認します。また、VGの空き容量が回復していることも合わせて確認すると安心です。

vgs
lvs

この「作成 → 更新作業 → 差分確認 → 成功なら削除・失敗ならロールバック」のサイクルを標準化することが、LVMスナップショット活用の核心です。チームで運用する場合は、スナップショットの命名規則（例：元LV名_snap_YYYYMMDD）を統一しておくと、誰が作成したものか一目でわかり、放置を防げます。

2026年現行環境での差分と注意点

ここ数年でLVM周りの環境はいくつか変化しています。2026年時点での主な差分を整理します。

シンプロビジョニングスナップショットが主流に

RHEL 9系（AlmaLinux 9、Rocky Linux 9を含む）やUbuntu 22.04以降の環境では、シンプロビジョニング（thin provisioning）が積極的に推奨されています。シンスナップショットはあらかじめCoW領域サイズを指定しなくてよく、プール容量の範囲内で自動的に伸長します。

# シンプール上のLVに対するスナップショット作成（サイズ指定不要）
lvcreate -s --name lv_root_snap vg0/lv_root

ただしシンスナップショットのロールバックは従来型と操作が異なります。lvconvert --mergeはシンスナップショットには対応していないため、元LVのアクティベートを一度外してスナップショットをリネームするか、lvconvertでシックへ変換する手順が必要になります。シンプロビジョニング環境でロールバック手順を標準化する際は、事前に手順を検証しておくことが不可欠です。

systemd-boot 環境でのカーネル更新への注意

Ubuntu 24.04 LTS以降ではsystemd-bootをデフォルトで採用するケースが増えており、カーネル更新時のブートローダー操作がGRUBと異なります。ルートLVのスナップショットを使ったロールバック後、ブートエントリがスナップショット前の状態と一致しているか確認が必要です。カーネル更新を伴う場合は、スナップショット取得のタイミングをカーネルインストール前に設定してください。

クラウド・仮想環境との組み合わせ

AWSのEBSスナップショットやProxmox VEのCTスナップショットなど、ハイパーバイザー・ストレージ層のスナップショット機能が充実したことで、「どのレイヤーでスナップショットを取るか」が運用設計の選択肢になっています。LVMスナップショットはOS内部で完結するため追加コストが不要な反面、ディスク障害への耐性はありません。クラウド環境ではストレージスナップショットとの使い分け、もしくは併用が現実的な選択肢です。

いずれの環境でも「スナップショットは作業の切り戻し手段であり、バックアップの代替ではない」という原則は変わりません。この区別を運用チーム内で共有しておくことが、インシデント時の混乱を防ぐ第一歩です。