Mastering Linux LVM: From Basics to Disaster Recovery Strategies

LVM Introduction

What Is LVM?

LVM (Logical Volume Manager) was originally developed by IBM for AIX and later ported to Linux in 1998. It creates a logical layer between physical disks and partitions, allowing multiple partitions or disks to be combined into a single logical volume, thereby increasing flexibility in disk management.

Initially used mainly on servers with RAID for high reliability, LVM has become popular on desktop PCs as disk capacities grew and prices fell. While PCs lack hardware redundancy, LVM offers disaster‑recovery features to mitigate data loss.

Listing 1: Check LVM Version

rpm -qa | grep lvm
lvm2-2.02.56-8.el5_5.4

The example shows LVM version 2.02.56 installed.

Basic LVM Concepts: PV, LV, VG, VGDA

Physical Volume (PV) : The lowest layer in LVM; can be an entire disk or a partition, identified by a name such as hdisk0 .

Logical Volume (LV) : Built on top of a volume group; multiple LVs can share the free space of a VG and can be resized dynamically.

Volume Group (VG) : Aggregates one or more PVs; all PVs belong to a VG (e.g., rootvg ).

Volume Group Descriptor Area (VGDA) : Stores metadata describing PVs, VGs, and LVs, similar to a partition table but located at the start of each PV.

Figure 1: Linux LVM Architecture

Fundamental LVM Disaster Recovery Approach

Types of Disasters

File‑system disasters are divided into human‑induced (e.g., accidental deletions, partition table corruption) and natural (e.g., hardware failure, bad sectors). LVM shares the same natural risks as ordinary file systems but also introduces LVM‑specific human risks such as VG, LV, or PV corruption.

Recovery Strategies

Enterprises typically rely on strict procedures, backup policies, and hardware redundancy. Individual users should back up data, especially LVM configuration files, and use LVM’s built‑in backup tools to restore PV, LV, or VG metadata after a failure.

When hardware failure renders the entire LVM unusable, LVM’s tools can restore availability and recover data from the underlying disks.

LVM Disaster Recovery Procedures

Logical Volume Corruption

Example environment: a PC with two disks (Disk‑A and Disk‑B) on an x86 architecture.

Listing 2: Inspect Disk and File‑System Status

linux-c3k3:~ # pvs
 PV         VG     Fmt  Attr PSize PFree
 /dev/sdb   system lvm2 a-   2.00G 92.00M
 /dev/sdc   system lvm2 a-   2.00G     0

linux-c3k3:~ # vgs
 VG     #PV #LV #SN Attr   VSize  VFree
 system   2   1   0 wz--n- 4.00G 92.00M

linux-c3k3:~ # lvs -o +devices
 LV    VG     Attr   LSize   Origin Snap%  Move Log Copy%  Devices
 alpha system -wi-ao   3.90G                               /dev/sdc(0)
 alpha system -wi-ao   3.90G                               /dev/sdb(0)

linux-c3k3:~ # mount |grep '/dev/mapper'
 /dev/mapper/system-alpha on /alpha type reiserfs (rw,acl,user_xattr)

Scenario 1: No physical disk failure, only logical errors.

Listing 3: Attempt to Re‑initialize a PV

linux-c3k3:~ # pvcreate -ff /dev/sdb
 Really INITIALIZE physical volume "/dev/sdb" of volume group "system" [y/n]? y
 Can't open /dev/sdb exclusively.  Mounted filesystem?

Because the PV contains an LV, the command is rejected. The next step is to erase the LVM label while preserving the partition table.

Listing 4: Erase LVM2 Label and Check Status

linux-c3k3:~ # dd if=/dev/zero of=/dev/sdb bs=512 count=1 seek=1
 1+0 records in
 1+0 records out
 512 bytes (512 B) copied, 9.8e-05 seconds, 5.2 MB/s

linux-c3k3:~ # pvs --partial
 Partial mode. Incomplete volume groups will be activated read‑only.
 ...
 PV             VG     Fmt  Attr PSize PFree
 /dev/sdc       system lvm2 a-   2.00G     0
 unknown device system lvm2 a-   2.00G 92.00M 

linux-c3k3:~ # vgs --partial
 ...
 VG     #PV #LV #SN Attr   VSize  VFree
 system   2   1   0 rz-pn- 4.00G 92.00M 

linux-c3k3:~ # lvs --partial
 ...
 LV    VG     Attr   LSize   Origin Snap%  Move Log Copy%
 alpha system -wi-ao   3.90G

The PV appears as an unknown device, but the LV remains accessible. Mount the filesystem read‑only and back up the data.

Listing 5: Mount Read‑Only and Backup

linux-c3k3:~ # mount -o remount -o ro /alpha

Backup steps are omitted for brevity.

Listing 6: Recovery Operations

* If "Can't open /dev/sdb exclusively" appears, deactivate the VG first.
 linux-c3k3:~ # pvcreate -ff --uuid 7m0QBR-3kNP-J0fq-GwAq-iv6u-LQkF-yhJh5R \
 --restorefile /etc/lvm/backup/system /dev/sdb
 Physical volume "/dev/sbd" successfully created

 linux-c3k3:~ # pvs
 PV         VG     Fmt  Attr PSize PFree
 /dev/sdb   system lvm2 a-   2.00G 92.00M
 /dev/sdc   system lvm2 a-   2.00G     0

 linux-c3k3:~ # vgcfgrestore -f /etc/lvm/backup/system system
 Restored volume system

 linux-c3k3:~ # vgchange – ay system
 1 logical volume(s) in volume group "system" now active

After activation, run a file‑system check to ensure integrity.

Scenario 2: PV Damage and Replacement

Listing 7: Current Disk Status

(none):/test # pvs
 PV         VG     Fmt  Attr PSize PFree
 /dev/sda2  system lvm2 a-   7.93G    0
 /dev/sdb   test   lvm2 a-   2.00G    0
 /dev/sdc   test   lvm2 a-   2.00G    0
 /dev/sdd          lvm2 --   2.00G 2.00G

... (vg and lv listings omitted for brevity)

Backup the /etc/lvm/backup directory, then corrupt /dev/sdc with dd to simulate failure.

Listing 9: Simulate PV Failure with dd

(none):/ # dd if=/dev/zero of=/dev/sdc bs=512 count=400
 400+0 records in
 400+0 records out
 204800 bytes (205 kB) copied, 0.046619 seconds, 4.4 MB/s

... pvs --partial output shows an unknown device for /dev/sdc ...

Attempt to mount the LV; the file system is reported as damaged.

Listing 11: Replace Failed PV

(none):/ # pvcreate --restorefile /etc/lvm/backup/test \
 --uuid noOzjf-8bk2-HJhC-92fl-2f6Q-DzNZ-XBqnBO /dev/sdd
 Physical volume "/dev/sdd" successfully created.

 (none):/ # pvs -v
 PV         VG     Fmt  Attr PSize PFree DevSize PV UUID
 /dev/sda2  system lvm2 a-   7.93G    0    7.93G HsErSz-...
 /dev/sdb   test   lvm2 a-   2.00G    0    2.00G OBb3qb-...
 /dev/sdd   test   lvm2 a-   2.00G    0    2.00G noOzjf-...

After replacement, the metadata becomes consistent.

Listing 12: Synchronize Metadata

(none):/ # vgchange -an test
 Volume group test metadata is inconsistent
 ...
 (none):/ # vgchange -ay test
 1 logical volume(s) in volume group "test" now active

Now the LV can be mounted and the data verified.

Bad Blocks Handling

LVM provides three levels of bad‑block handling: internal disk relocation (transparent to the user), LVM‑generated hardware relocation, and software relocation via a bad‑block table. Users can disable the Bad Block Relocation Area (BBRA) with lvcreate –r n for root and swap LVs.

Disk Position Changes

If a disk is moved within the same system, LVM automatically detects the change. For multiple VGs, deactivate the VG before moving the disk and reactivate it afterward.

Listing 15: Reactivate a VG

# vgchange – a n /dev/system   # deactivate
 # vgchange – a y /dev/system   # activate

When moving disks between systems, export the VG, move the hardware, then import and activate it.

Listing 16: Export VG

# vgexport /dev/system
 Volume group "system" successfully exported

Listing 17: Import and Activate VG

# vgimport /dev/system
 Volume group "system" successfully imported
 # vgchange – a y /dev/system
 1 logical volume(s) in volume group "system" now active

Disk Damage Scenarios

For non‑root partitions, replace the failed disk and re‑mount the LVM volumes. For root‑partition damage, boot from rescue media, use vgreduce –‑removemissing to drop missing PVs, then reactivate the remaining LVs.

Listing 21: Remove Missing PVs

# vgreduce –‑removemissing system
 Wrote out consistent volume group system

Listing 22: Activate Restored LVs

# lvchange – ay /dev/system
 ACTIVE '/dev/system/root'[7.38 GB] inherit
 ACTIVE '/dev/system/swap'[560.00 MB] inherit

After activation, the system boots normally, and data on the surviving disks remains intact.