「消してしまった…」その時、あなたを救う最後の手段。
こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全8回にわたるLVM完全マスター連載も、今回でついに最終回です。
これまで、LVMの構築、拡張、縮小、スナップショットと、便利な機能を使い倒してきました。
しかし、どんなに便利な道具でも、操作するのは人間です。
疲れている深夜作業で、間違って大切なデータが入ったLVを削除してしまったら…？
先生、顔面蒼白です…。
テスト環境のつもりが、本番環境で lvremove を打ってしまいました。/data が消えました。バックアップは昨日のが最後です。
今日の分のデータ、なんとかして戻せないでしょうか！？ クビが飛びそうです！
深呼吸して、コウ君。
まだディスクの中身が上書きされていなければ、LVMには「起死回生の一手」が残されているわ。
LVMは操作を行うたびに、自動的に設定のバックアップを取っているの。
それを使えば、削除する直前の状態に時間を巻き戻せるわよ！
今回は、LVM運用の総決算。
誤操作からの復旧技術（メタデータリストア）と、ハードウェア障害に備えるための「RAIDとの組み合わせ」について解説します。
これをマスターすれば、あなたは真の意味で「サーバーを守れるエンジニア」になれます。
📚 LVM完全マスター（全8回）目次
現在地：【第8回】LVMトラブルシューティングとRAID構成
第1章：誤って削除したLVを復活させる「vgcfgrestore」
これが今回最大の目玉テクニックです。lvremove コマンドで論理ボリュームを削除すると、OSからは見えなくなりますが、ディスク上のデータ領域（0と1の並び）が即座に消されるわけではありません。
「ここはデータがある場所だよ」という地図（メタデータ）が消されただけです。
つまり、「地図」さえ復元できれば、データは戻ってきます。
1. バックアップファイルの在り処
LVMは設定変更（作成・削除・拡張など）を行うたびに、自動的にメタデータのバックアップを以下のディレクトリに保存しています。
/etc/lvm/archive/
まずはここを確認してみましょう。
ls -lt /etc/lvm/archive/ | head
ファイル名は VG名_番号.vg となっています。
タイムスタンプを見て、「削除してしまう直前」のファイルを探します。
2. バックアップの中身を確認する
見つけたファイル（例：vg_storage_00123.vg）の中身を less や cat で確認します。
cat /etc/lvm/archive/vg_storage_00123.vg
中にはVGの構成情報がテキストで書かれています。logical_volumes { ... } のセクションに、消してしまったはずのLV（lv_data）の定義が残っていれば、それが「正解」のバックアップファイルです。
3. 復元コマンドを実行
復元には vgcfgrestore コマンドを使います。
sudo vgcfgrestore -f /etc/lvm/archive/vg_storage_00123.vg vg_storage
-f：使用するバックアップファイルを指定。- 最後の引数：対象のVG名。
実行結果：
Restored volume group vg_storage
これで地図（メタデータ）が戻りました。
4. LVをアクティブにする
復元直後のLVは、安全のため「非アクティブ（停止）」状態になっています。
以下のコマンドで有効化します。
sudo lvchange -a y /dev/vg_storage/lv_data
その後、マウントしてみましょう。
sudo mount /dev/vg_storage/lv_data /data
中のファイルが無事であれば、復旧成功です！
（※もし削除後に別のLVを作成するなどしてディスク領域が上書きされていた場合、データは壊れています。あくまで「削除直後」なら助かる可能性が高い、という技術です）
第2章：物理ディスク障害時の対応
次は、ハードウェア障害です。
LVM自体には冗長性（RAID機能）を持たせることも可能ですが、設定が複雑で一般的ではありません。
「PVが1本死んだら、VG全体が死ぬ」のがLVMの基本仕様です。
障害ディスクの切り離し「vgreduce –removemissing」
もしPV（/dev/sdb1）が物理的に故障して認識しなくなった場合、LVMコマンドを打つたびにエラーが出たり、ハングアップしたりします。
生き残っている他のPVだけでも救出するために、死んだPVをVGから強制的に切り離すコマンドがこれです。
sudo vgreduce --removemissing --force vg_storage
これを実行すると、故障したPVに乗っていたLVは完全に失われますが、無事なPVに乗っていたLVはアクセス可能になります。
「損切り」をして、生きているデータを守るためのコマンドです。
第3章：LVM × RAID ＝ 最強のインフラ
LVMの弱点である「冗長性のなさ」を補うために、Linuxサーバー構築の現場では「mdadm（ソフトウェアRAID）」と組み合わせるのが鉄板の構成です。
階層構造のイメージ
- 物理ディスク：
/dev/sdb,/dev/sdc（2本のHDD） - RAID層（mdadm）： 上記2本を束ねて、RAID 1（ミラーリング）を作成。
→ デバイス名：/dev/md0 - LVM層（PV）：
/dev/md0をPVとして作成。 - VG/LV： あとは通常通り。
この構成にしておけば、HDDが1本壊れてもRAID層が守ってくれるため、LVMやファイルシステムは何の影響も受けずに動き続けます。
LVMの柔軟性とRAIDの堅牢性を両立させる、プロの設計です。
構築手順（概要）
# 1. RAID 1の作成 sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1 # 2. PVの作成（RAIDデバイスに対して行う） sudo pvcreate /dev/md0 # 3. VGの作成 sudo vgcreate vg_raid /dev/md0
あとは今まで通りです。
本番環境を構築する際は、ぜひこの「LVM on RAID」構成を検討してください。
第4章：よくあるトラブルQ&A事例集
最後に、現場でよく遭遇するエラーメッセージとその対処法をまとめました。
Q1. “WARNING: Device /dev/sdb1 not found.”
状況： サーバー起動時やLVMコマンド実行時に表示される。
原因： 指定されたPVが見つかりません。ディスクが故障しているか、ケーブルが抜けているか、仮想環境なら設定でディスクをデタッチしてしまった可能性があります。
対策： lsblk でディスクが見えているか確認。見えていなければハードウェアの問題です。
Q2. “Found duplicate PV … using /dev/sdb1”
状況： pvs などを打つと「重複（duplicate）」という警告が出る。
原因： 仮想マシンのクローン（コピー）を行った時によく起きます。LVMはディスクを「UUID」というIDで識別していますが、クローンするとUUIDまで全く同じディスクが2つ存在することになり、LVMが混乱します。
対策： vgimportclone コマンドを使って、片方のディスクのUUIDを書き換えてインポートし直す必要があります。
Q3. “device-mapper: reload ioctl on … failed: Device or resource busy”
状況： スナップショットのマージやLV削除時に出る。
原因： そのLVがまだマウントされているか、誰か（プロセス）が掴んでいます。
対策： 確実にアンマウントする。それでもダメなら lsof /data などでアクセスしている犯人（プロセス）を探して停止させてください。
連載まとめ：LVMを制する者はインフラを制す
全8回、本当にお疲れ様でした。
ここまで読み通したあなたは、もう「LVM初心者」ではありません。
ディスクの増減自在、バックアップ自在、そして障害復旧までこなせる「ディスク管理のエキスパート」です。
LVM完全マスターコース修了要件：
- ✅ PV/VG/LVの3層構造を理解している。
- ✅ 稼働中にlvextendで容量を増やせる。
- ✅ スナップショットで安全に作業できる。
- ✅ vgcfgrestoreで削除事故から生還できる。
クラウド全盛の時代ですが、クラウドの裏側で動いている技術も結局はLinuxであり、LVMです。
この連載で身につけた知識は、AWSでも、オンプレミスでも、自宅サーバーでも、一生使える武器になります。
あなたのインフラエンジニアとしての人生が、このLVMの知識でより自由で、強固なものになることを願っています。
それでは、また別の連載でお会いしましょう！
▼ ネクストステップはこちら ▼
RAID構成を試すなら
「VPS」で実験環境
サーバー知識を年収に
「ITエンジニア転職」
コメント