LVM basics: managing and recovering logical volumes
Quick answer
LVM (Logical Volume Manager) sits between your raw disks and your filesystems. Physical disks become physical volumes, physical volumes are pooled into a volume group, and the volume group is carved into logical volumes that you actually format and mount. Inspect the stack with pvs, vgs and lvs. If a volume group doesn't show up after booting into a rescue environment, it usually just needs activating: run vgscan followed by vgchange -ay.
The LVM stack, layer by layer
LVM adds a layer of abstraction between physical storage and the filesystems you actually use. Instead of formatting a partition directly, you build the stack in three steps:
- Physical volume (PV). A disk or partition initialised for use by LVM. This is the raw material.
- Volume group (VG). A pool made up of one or more physical volumes. Capacity from every physical volume in the group is combined into one pool of space.
- Logical volume (LV). A chunk of space carved out of a volume group. A logical volume is what you format with a filesystem and mount, in the same way you'd otherwise mount a plain partition.
The chain runs one way: physical volumes make up a volume group, and a volume group is divided into logical volumes. Nothing above the volume group cares which physical disk a given block actually lives on, that indirection is the whole point.
Why bother with LVM
A plain partition is fixed the moment it's created: its size, and which physical disk it lives on, are both set in stone unless you repartition. LVM removes both constraints:
- Resize without repartitioning. As long as a volume group has free space, a logical volume can be grown (and, depending on the filesystem, shrunk) without touching partition tables at all.
- Span multiple physical disks. A volume group can pool space from several physical volumes, so a logical volume can be larger than any single underlying disk.
- Snapshot a volume. LVM can take a point-in-time snapshot of a logical volume, useful for taking a consistent backup of a volume that's still being written to, or for having a rollback point before a risky change.
The trade-off is an extra layer to reason about when something goes wrong, which is exactly the recovery scenario covered below.
Inspecting the stack
Each layer has a short summary command and a detailed one. Start with the summary commands to get your bearings:
| Layer | Summary command | Detail command |
|---|---|---|
| Physical volumes | pvs | pvdisplay |
| Volume groups | vgs | vgdisplay |
| Logical volumes | lvs | lvdisplay |
The summary commands (pvs, vgs, lvs) list one line per item, which is usually enough to see what exists and how much space is used or free. The *display commands print a full attribute block per item, useful when you need specifics like a volume group's exact extent size or a logical volume's full device path.
Recovering a volume group that isn't showing up
A common situation after booting into a rescue environment (see What is rescue mode, and when do you need it): the server's normal disks are visible at the block-device level, but vgs or lvs comes back empty, or the volume group you expect just isn't listed. This is expected, not necessarily a sign of corruption. Rescue mode boots a separate, minimal environment that doesn't automatically know about or activate a volume group living on another disk, in the same way it doesn't automatically assemble a software RAID array or unlock encrypted storage.
Scan for volume groups
vgscan reads the physical volumes it can see and rebuilds LVM's knowledge of what volume groups exist on them:
vgscanActivate the volume group
Scanning makes the volume group visible but not necessarily active. Activate every volume group vgscan found:
vgchange -ayTo activate a single named volume group instead of all of them, pass its name:
vgchange -ay vg_dataConfirm and mount
Run lvs again to confirm the logical volumes are now visible, then mount the one you need as you would any other block device. See Mounting a disk in Linux for that step.
lvs
mount /dev/vg_data/lv_data /mnt/recoveryIf the volume group still doesn't appear after vgscan, check that the underlying physical volumes are actually visible with pvs first. A volume group can only be found if every physical volume it depends on is reachable, a disk that failed to come up, or a RAID array that hasn't been assembled yet, will keep the volume group hidden regardless of how many times you scan.