LVM: Logical Volumes & Snapshots

In Disks & Storage you formatted a whole disk and mounted it. That works until the disk fills up. Then you face a hard question: how do you make /var/www bigger without copying everything to a new disk and taking the site offline? LVM, the Logical Volume Manager, answers it. It puts a flexible layer between disks and filesystems, so you can grow volumes while they are in use, spread one volume across several disks, and take instant snapshots.

LVM is everywhere in real work. The Ubuntu Server installer uses it in its default guided layout, and RHEL, Rocky and AlmaLinux install onto LVM by default. Sooner or later a ticket will say "the root filesystem is 95% full", and LVM is how you fix it in two commands.

Three layers: PV, VG and LV

Think of a family's money: each person's salary is a PV, the joint account is the VG, and the monthly budgets for rent and school fees are the LVs. You can move money between budgets or add a new salary without opening a new account. Space in a VG is handed out in extents, blocks of 4 MiB by default.

Three short commands show each layer. On a fresh Ubuntu Server VM with a 50 GB disk they might show:

sudo pvs
sudo vgs
sudo lvs

PV         VG        Fmt  Attr PSize   PFree
/dev/sda3  ubuntu-vg lvm2 a--  <48.00g <24.00g
VG        #PV #LV #SN Attr   VSize   VFree
ubuntu-vg   1   1   0 wz--n- <48.00g <24.00g
LV        VG        Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
ubuntu-lv ubuntu-vg -wi-ao---- 24.00g

Look at VFree: half of the volume group is unused. Depending on the version and the disk size, the installer's guided layout can leave space unallocated like this, so a server reports a full root filesystem while gigabytes sit idle in the VG. The < sign means "slightly less than", because sizes are rounded to whole extents. For more detail, use pvdisplay, vgdisplay and lvdisplay.

Growing a logical volume online

Growing is the most common LVM task and is safe while the filesystem is mounted and in use. lvextend enlarges the LV, and -r (--resizefs) grows the filesystem inside it in the same step:

df -h /
sudo lvextend -r -l +100%FREE ubuntu-vg/ubuntu-lv
df -h /

Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv   24G   22G  1.1G  96% /
  Size of logical volume ubuntu-vg/ubuntu-lv changed from 24.00 GiB (6144 extents) to <48.00 GiB (12287 extents).
...
The filesystem on /dev/ubuntu-vg/ubuntu-lv is now 12581888 (4k) blocks long.
...
  Logical volume ubuntu-vg/ubuntu-lv successfully resized.
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv   47G   22G   24G  48% /

-l +100%FREE means "add all free extents"; -L +10G would add exactly 10 GiB. No reboot, no unmount, and the website kept running. (Outputs here are traced from the LVM and resize2fs manual pages; the middle lines were shortened.)

Building a new volume group

Suppose Priya adds a second 50 GB disk, /dev/sdb, for website data. Create each layer in order, then format and mount the LV like any partition:

sudo pvcreate /dev/sdb
sudo vgcreate datavg /dev/sdb
sudo lvcreate -n www -L 20G datavg
sudo mkfs.ext4 -L www /dev/datavg/www
sudo mkdir -p /srv/www
sudo mount /dev/datavg/www /srv/www

  Physical volume "/dev/sdb" successfully created.
  Volume group "datavg" successfully created
  Logical volume "www" created.
...

The LV appears as /dev/datavg/www (also reachable as /dev/mapper/datavg-www). Unlike /dev/sdb, these names do not change when disks are added, so they are safe to use in /etc/fstab:

/dev/datavg/www  /srv/www  ext4  defaults  0  2

Test it with sudo findmnt --verify and sudo mount -a, as you learned before. Only 20 GiB of the 50 GB disk is used; the rest stays in the pool for whichever volume needs it first.

When the VG itself runs out, add another disk to it. vgextend adds the new PV to the pool, and the existing LV can grow onto it at once:

sudo pvcreate /dev/sdc
sudo vgextend datavg /dev/sdc
sudo lvextend -r -L +30G datavg/www

The www volume now spans two physical disks, and applications see only one bigger filesystem. On cloud servers you often do something similar without a new disk: enlarge the virtual disk in the provider's panel, grow the partition with growpart, then run sudo pvresize /dev/sda3 so LVM sees the extra space.

Snapshots for consistent backups

An LVM snapshot is a frozen, point-in-time view of an LV, created in about a second. It does not copy the data. Instead, when a block on the original is about to change, LVM first copies the old block into the snapshot's space. A snapshot therefore only needs room for the changes made while it exists.

This solves a real backup problem. Copying a busy folder takes minutes, and files change during the copy, so the backup mixes old and new versions. Back up a snapshot instead, and every file comes from the same instant:

sudo lvcreate -s -n www-snap -L 2G datavg/www
sudo lvs datavg
sudo mkdir -p /mnt/www-snap
sudo mount -o ro /dev/datavg/www-snap /mnt/www-snap
sudo tar -czf /srv/backups/www-$(date +%F).tar.gz -C /mnt/www-snap .
sudo umount /mnt/www-snap
sudo lvremove -y datavg/www-snap

Logical volume "www-snap" created.
LV       VG     Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
www      datavg owi-aos--- 20.00g
www-snap datavg swi-a-s---  2.00g      www    0.01
Logical volume "www-snap" successfully removed.

-s makes a snapshot, and -L 2G reserves space for changes. The o and s at the start of the Attr column mark the origin and the snapshot, and Data% shows how much of the snapshot's space is used. Watch it: if a snapshot fills to 100%, it becomes invalid and useless. Remove snapshots as soon as the backup is done, because every write to the origin costs extra work while one exists. You will use this in Backups & Restores: tar, rsync & Snapshots.

A snapshot also works as an "undo" point before a risky change, such as a major upgrade of a web application. If the upgrade fails, sudo lvconvert --merge datavg/www-snap rolls the volume back to the snapshot (the merge finishes the next time the volume is activated if it is in use). A snapshot on the same disks is not a backup: if the disk dies, the original and the snapshot die together.

Common mistakes

• Running resize2fs or xfs_growfs separately and forgetting it. The LV grows but df shows no change. Use lvextend -r.
• Shrinking an LV before its filesystem. Data loss. Avoid shrinking; plan to grow.
• Leaving snapshots around. They slow writes and silently fill up to 100%.
• Using all VG space at install time. Keep some free extents for emergencies.
• Treating snapshots as backups. Copy the data somewhere else.

Key points

• LVM layers: physical volumes (disks) form a volume group (pool), which is divided into logical volumes.
• pvs, vgs and lvs show each layer; VFree in vgs is unallocated space.
• lvextend -r -L +10G vg/lv grows a volume and its filesystem online.
• pvcreate plus vgextend adds a disk to a pool; pvresize uses a disk that was enlarged.
• lvcreate -s takes a snapshot for consistent backups or rollback; remove it after use.

lsblk /dev/sdd
sudo pvcreate /dev/sdd
sudo vgextend datavg /dev/sdd
sudo lvextend -r -L +40G datavg/mysql
sudo vgs datavg
df -h /var/lib/mysql

  VG     #PV #LV #SN Attr   VSize   VFree
  datavg   2   2   0 wz--n- 149.99g 64.99g
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/datavg-mysql   69G   28G   38G  43% /var/lib/mysql