【LVM完全マスター第7回】失敗しても過去に戻れる!LVMスナップショットによる「タイムマシン」バックアップ術

「Enterキーを押すのが怖い」すべてのエンジニアへ。

こんにちは!「LINUX工房」管理人の「リナックス先生」です。
前回は、ディスク容量の縮小や物理ディスクの交換といった、少し高度な運用テクニックを学びました。

さて、サーバー管理者には、冷や汗が止まらない瞬間があります。
「OSのバージョンアップ」「ミドルウェアのパッチ適用」、あるいは「複雑な設定ファイルの書き換え」を行う直前です。

コウ君

先生、聞いてください。
明日、本番サーバーのカーネルアップデートを任されちゃいました…。
もし起動しなくなったらどうしよう。
バックアップを取りたいけど、数百GBもあるデータをコピーするには何時間もかかるし、サービスを止めるわけにもいかないんです!

リナックス先生

そんな時こそ「LVMスナップショット」の出番よ。
これを使えば、たとえデータが10TBあっても、コマンド一発、わずか1秒でその瞬間の状態を保存できるわ。
もしアップデートに失敗しても、タイムマシンのように作業前の状態へ「巻き戻す」ことができるの。
エンジニアにとっての最強の保険、使い方をマスターしましょう!

本記事では、LVMスナップショットの仕組み(Copy On Write)から、作成・確認・リストアの手順、そして運用時に最も注意すべき「容量溢れ」のリスク管理までを徹底解説します。

📚 LVM完全マスター(全8回)目次

現在地:【第7回】スナップショット機能で一瞬でバックアップを取る


第1章:なぜ「一瞬」でバックアップできるのか?(COWの仕組み)

通常のバックアップ(コピー)は、データ量に応じて時間がかかります。
しかし、LVMスナップショットはデータ量に関わらず一瞬で完了します。
なぜそんなことが可能なのでしょうか?

Copy On Write(カウ:書き込み時コピー)

LVMスナップショットは、作成した時点ではデータをコピーしません。
「今の状態を記録した目次(ポインタ)」を作るだけです。
だから一瞬で終わります。

その後、元のデータに変更が加えられた時だけ、変更前の古いデータをスナップショット領域に避難(コピー)させます。
これをCopy On Write (COW) と呼びます。

スナップショットの視点:
「変更されていないデータ」は元の場所を見に行き、「変更されたデータ」は避難場所を見に行きます。
これにより、スナップショット側からは常に「作成した時点の姿」が見え続けるのです。

⚠️ 重要:容量は「変更分」だけあればいい
スナップショット領域には「変更された差分」しか保存されません。
そのため、元のデータが100GBあっても、変更予定が1GB程度なら、スナップショットの容量は数GBあれば十分足ります。
(逆に言うと、変更分が容量を超えるとスナップショットは壊れます。詳しくは後述。)


第2章:スナップショットの作成「lvcreate -s」

それでは実践です。
前回までに作成した /dev/vg_storage/lv_data (マウント先:/data)のスナップショットを取ってみましょう。

1. 準備:VGに空き容量があるか確認

スナップショット領域(変更データの避難場所)を作るために、VGに空き容量が必要です。

sudo vgs

VFree が十分に(今回は数GB程度)あることを確認してください。

2. 作成コマンド

通常のLV作成と同じ lvcreate コマンドを使いますが、-s (snapshot) オプションを付けます。

sudo lvcreate -s -n lv_data_snap -L 1G /dev/vg_storage/lv_data
  • -s : スナップショットを作成する。
  • -n lv_data_snap : スナップショットの名前(任意)。分かりやすく _snap などを付けるのが通例。
  • -L 1G : スナップショット領域のサイズ。「どれだけの変更に耐えられるか」を決める。元データの10〜20%程度確保するのが一般的。
  • 最後の引数 : 対象となる元のLV(/dev/vg_storage/lv_data)。

実行結果:

  Logical volume "lv_data_snap" created.

これでバックアップ完了です。
サービスを止める必要も、アンマウントする必要もありません。


第3章:スナップショットの確認と活用

作成したスナップショットがどうなっているか見てみましょう。

1. 状態確認「lvs」

sudo lvs

出力例:

  LV           VG         Attr       LSize Pool Origin  Data%
  lv_data      vg_storage owi-aos--- 20.00g
  lv_data_snap vg_storage swi-a-s---  1.00g      lv_data 0.01
  • Origin: スナップショットの親(元データ)が lv_data であることが分かります。
  • Data%: ここが超重要! スナップショット領域の使用率です。
    元データに変更が加わるたびに、この数値が上がっていきます。
    これが100%になるとスナップショットは無効(Invalid)になり、二度と使えなくなります。

2. 中身を見てみる(マウント)

スナップショットも、普通のLVと同じようにマウントできます。
「バックアップ時点のファイルを取り出したい」という時に便利です。

sudo mkdir /mnt/snap
sudo mount /dev/vg_storage/lv_data_snap /mnt/snap

※XFSの場合は、UUIDが重複しているためエラーになります。-o nouuid オプションを付けてマウントします。
sudo mount -o nouuid /dev/vg_storage/lv_data_snap /mnt/snap

/mnt/snap の中を見ると、スナップショットを作成した瞬間のファイルが見えるはずです。
元データの /data に新しいファイルを作っても、/mnt/snap には反映されません。
まさに「時間が止まっている」状態です。


第4章:過去に巻き戻す(リストア)「lvconvert –merge」

さあ、いよいよ本番です。
「作業ミスで重要なファイルを消してしまった!」「設定変更したら動かなくなった!」
そんな時、スナップショットを使って元の状態に戻します。

手順1:アンマウントする

リストア(マージ)を行うには、元データをアンマウントする必要があります。
(※ルートパーティションの場合は後述)

sudo umount /data

また、もしスナップショット自体をマウントしている場合は、それもアンマウントします。

sudo umount /mnt/snap

手順2:マージ(結合)を実行する

コマンドは lvconvert --merge です。

sudo lvconvert --merge /dev/vg_storage/lv_data_snap

実行結果:

  Merging of volume vg_storage/lv_data_snap started.
  lv_data: Merged: 100.0%

これで完了です。
/dev/vg_storage/lv_data は、スナップショット作成時点の状態に完全に巻き戻りました。
そして、役目を終えたスナップショット(lv_data_snap)は自動的に削除されます。

手順3:再マウントして確認

sudo mount /data
ls /data

消してしまったファイルが復活しているはずです。


第5章:【応用】ルートファイルシステム(/)のリストア

データ領域(/data)なら簡単ですが、OSそのものが入っている ルートファイルシステム(/) を巻き戻したい場合はどうすればいいでしょうか?
/ は稼働中にアンマウントできないため、少し挙動が変わります。

手順1:マージコマンドを実行

sudo lvconvert --merge /dev/cl/root_snap

すると、以下のようなメッセージが出ます。

  Can't merge over open origin volume.
  Merging of volume cl/root_snap will occur on next activation of cl/root.

「今は開いているから無理だよ。次の起動時にマージするよ」と言われます。

手順2:再起動する

sudo reboot

再起動中、OSが立ち上がる前の段階(dracut/initramfs)でLVMがマージ処理を自動実行します。
OSが起動してきた時には、すでに過去の状態に戻っています。
これが「システム更新失敗時の切り戻し」の鉄板手順です。


第6章:運用上の注意点とリスク管理

非常に便利なスナップショットですが、運用を間違えると痛い目を見ます。

1. スナップショットは「バックアップ」ではない

これはあくまで「一時的な変更履歴」です。
元のディスクが物理的に故障したら、スナップショットも一緒に死にます。
恒久的なデータ保護には、別のディスクやサーバーへのコピーが必要です。

2. 容量溢れ(Overflow)に注意!

前述の通り、Data% が100%になるとスナップショットは壊れ(Invalid)、リストアできなくなります。
大量のデータ変更が予想される場合は、スナップショット領域を大きめに確保するか、作業時間を短くする必要があります。

3. パフォーマンスへの影響

スナップショットが存在する間、元データへの書き込みが発生するたびに「コピー処理」が裏で走ります。
そのため、ディスクの書き込み性能(Write IOPS)が低下します。
作業が終わったら、速やかに削除(lvremove)するか、マージして消すのが鉄則です。

スナップショットの削除(マージせずに捨てる場合):

sudo lvremove /dev/vg_storage/lv_data_snap

第7章:トラブルシューティング Q&A

Q1. スナップショットの容量が足りなくなりそうです!

A. 稼働中に拡張できます。
普通のLVと同じく、lvextend でスナップショット領域を広げることができます。

sudo lvextend -L +1G /dev/vg_storage/lv_data_snap

これで Data% が下がり、延命できます。

Q2. 複数のスナップショットを作れますか?

A. はい、可能です。
ただし、パフォーマンスの低下が著しくなるため、推奨されません。
基本は「作業前に1つ作り、終わったら消す」運用を心がけましょう。


まとめ:スナップショットは「勇気」をくれる

お疲れ様でした!
今回はLVMの強力な機能、スナップショットをマスターしました。

今回の重要ポイント:

  • lvcreate -s で一瞬で状態保存。
  • 容量は「変更分」だけ消費する(Copy On Write)。
  • lvconvert --merge で過去にタイムスリップ。
  • ルートパーティションのリストアは再起動で自動実行される。
  • 長期間放置せず、用が済んだらすぐ消す。

これさえあれば、危険なコマンドも、未知のアップデートも怖くありません。
「失敗しても戻せばいい」という安心感が、エンジニアとしての積極的なチャレンジを支えてくれるはずです。

いよいよ次回は最終回、第8回「LVMトラブルシューティングとRAID構成」です。
「誤ってPVを消してしまった!」「起動しなくなった!」といった絶体絶命のピンチから生還するための、黒魔術的な復旧テクニックを紹介します。
最後までお見逃しなく!

▼ エンジニアとしてのキャリアを加速させる ▼

LVMを実践練習
「VPS」で環境構築

おすすめVPSを見る

インフラ技術を仕事に
「ITエンジニア転職」

転職エージェントを見る

コメント