Mastering LVM: From Basics to Advanced Migration, Backup & Recovery

This content originally appeared on DEV Community and was authored by mohideen sahib

Linux LVM (Logical Volume Manager) transforms static partitions into a flexible, portable, and recoverable storage layer. Beyond simple resizing, LVM enables migrations, RAID mirroring, disaster recovery, and SAN integrations (like NetApp).

This post takes you from fundamentals to deep operational concepts — including vgexport, vgimport, vgchange, vgrename, metadata recovery, RAID, and safe PV resizing practices.

1. LVM Building Blocks

pvcreate /dev/sdb
vgcreate vg_data /dev/sdb
lvcreate -n lv_app -L 50G vg_data
mkfs.ext4 /dev/vg_data/lv_app
mount /dev/vg_data/lv_app /mnt/app

2. Extending, Resizing & Removing Storage

Two Ways to Grow Storage — and Why One is Riskier

You can expand LVM capacity by either resizing a disk (existing PV) or adding a new disk (new PV) to your VG.

Scenario 1: Extending an Existing PV (Riskier)

If your underlying LUN or disk was expanded (say from 100 GB → 200 GB):

1. Rescan the device:

   echo 1 > /sys/class/block/sdb/device/rescan
   fdisk -l /dev/sdb

We may need to use resizepart if the lvm pv we want to increase is a partition and not a seperate disk

Start parted and print partition table:parted /dev/sdb
(parted) print
This shows all partitions and their numbers.
Resize the partition:(parted) resizepart 2 100%
Replace 2 with your partition number (e.g., /dev/sdb2).100% tells parted to extend the partition to use all available free space at the end of the disk.This operation is safe and does not delete or re-create the partition if there is unallocated space adjacent to the partition��.
Exit parted:(parted) quit

1. Resize the PV:

   pvresize /dev/sdb

1. Validate the VG:

   pvs
   vgdisplay vg_data

Now your VG reflects additional Free PE space.

Risks:

• Rescan failures or cached geometry can corrupt LVM metadata.
• Multipath or clustered systems may see inconsistent disk layouts.
• If expansion fails mid-process, recovery can be tricky.

Before resizing, take an LVM metadata backup:

vgcfgbackup vg_data

If corruption happens:

vgcfgrestore vg_data

(Only restores structure, not the actual data.)

Scenario 2: Adding a New Disk (Safer)

Instead of resizing an existing PV, add a new disk:

pvcreate /dev/sdc
vgextend vg_data /dev/sdc

Then expand an LV:

lvextend -L +50G /dev/vg_data/lv_app
resize2fs /dev/vg_data/lv_app

To remove later:

pvmove /dev/sdc
vgreduce vg_data /dev/sdc
pvremove /dev/sdc

Recommended for SAN/NetApp/Production systems
No dependency on device rescans or geometry changes
Easy rollback

Method	Description	Risk	Use Case
pvresize	Reclaims resized disk space	High	Virtual/Dev Environments
vgextend	Adds new PV to VG	Low	SAN/Physical Servers

3. Advanced LVM Operations

vgexport & vgimport

Used to migrate or clone VGs between systems without copying data.

vgexport

vgexport vg_data

• Marks VG as “exported” (hidden from local LVM)
• Does not delete data
• Safe before unmapping or SAN snapshot

vgimport

vgimport vg_data
vgchange -ay vg_data

• Reads PV headers
• Re-registers VG
• Clears export flag

Check usage:

pvs

PV         VG        Fmt  Attr PSize   PFree
/dev/sdb   vg_data   lvm2 x--  100.00g  0
/dev/sdc   vg_data   lvm2 a--  200.00g 50.00g

(x → exported, a → active)

vgrename

Used to rename a VG (especially useful after importing a clone).

vgrename vg_data vg_data_clone
vgscan --cache
lvs

Avoids duplicate VG name conflicts during SAN clone imports.

vgchange

Activate or deactivate a VG:

vgchange -ay vg_data   # Activate
vgchange -an vg_data   # Deactivate

Commonly used after imports or before unmounting for maintenance.

4. LVM Metadata Backup & Restore

LVM automatically stores metadata backups under /etc/lvm/backup/.

Manual backup:

vgcfgbackup vg_data

Restore only structure, not data:

vgcfgrestore vg_data

Use Cases

• VG corruption
• Accidental LV deletion
• Disk failure recovery

Remember:

Metadata backups restore the layout, not user data.
You’ll still need file-level recovery for lost contents.

5. LVM RAID & Mirroring (Modern Way)

LVM supports software RAID natively with --type raidX.
Avoid old -m mirror syntax except for legacy systems.

View RAID info:

lvs -a -o +devices,raid_sync_action

Convert an existing LV:

lvconvert --type raid1 -m1 vg_data/lv_app /dev/sdc

Repair or replace failed disk:

pvmove /dev/sdb /dev/sdf
vgreduce vg_data /dev/sdb
lvconvert --repair vg_data/lv_data

RAID Parity & Mirroring Notes:

• --type raid1 → Mirrors data across devices
• --type raid5/6/10 → Adds parity redundancy
• Modern kernels auto-sync during rebuilds
• Always prefer hardware RAID (NetApp, etc.) in enterprise setups

6. Using LVM with NetApp Snapshots

If your backend storage is NetApp, and you share a snapshot clone as a new LUN, you can:

1. Export the VG from the source:

   vgexport vg_data

1. Map the snapshot clone to a new host.
2. On the new host:

   vgimport vg_data
   vgrename vg_data vg_data_clone
   vgchange -ay vg_data_clone

Safely mount and test the clone.
No data copy. No downtime.

7. Migration Without Rsync

When moving volumes between servers:

vgexport vg_data
# Move or reattach disks/SAN
vgimport vg_data
vgchange -ay vg_data

Optionally rename VG:

vgrename vg_data vg_clone

No rsync required — data stays on the same blocks.
Ideal for SAN or virtualized migrations.

8. Quick Reference

Final Thoughts

• Always prefer adding new PVs over resizing existing ones.
• pvresize is convenient but riskier for production SANs.
• vgexport / vgimport make migrations and SAN snapshot reuses instant.
• LVM metadata backups restore structure only, not content.
• Modern LVM RAID offers software redundancy, but hardware RAID or NetApp mirrors are better for critical workloads.

LVM remains one of the most powerful abstractions in Linux storage, bridging raw disks, SANs, and enterprise reliability into one logical framework.

This content originally appeared on DEV Community and was authored by mohideen sahib