Using LVM Logical Volumes in Practice: Flexible Storage Management on Linux

1. Why LVM replaces classic partitions

LVM (Logical Volume Manager) is an additional abstraction layer between physical storage media and filesystems on Linux. Instead of dividing a disk directly into rigid partitions with a fixed size, LVM pools one or more disks into a shared storage pool from which flexible logical volumes are carved out. Anyone who has ever needed to grow a partition while a server stayed in production knows the problem: classic partition tables only allow that in limited ways, often requiring a reboot or a complete rebuild of the filesystem. LVM solves exactly this problem by decoupling the logical size of a volume from the physical arrangement of data on disk.

In practice, on servers running Magento or other PHP applications with growing databases and media directories, LVM is close to a standard requirement. A logical volume for /var/lib/mysql can be grown online as soon as the dataset grows, with no downtime and no data loss. Snapshots for consistent backups are also practically impossible on classic partitions without LVM. Anyone operating production Linux servers should plan for LVM from the start, even if the initial storage requirement looks small.

2. Physical Volume, Volume Group, Logical Volume

LVM is built on three central objects that build on each other. A Physical Volume (PV) is a complete disk or partition made available to LVM as raw material. Multiple physical volumes are combined into a Volume Group (VG), essentially a shared pot of storage. From this volume group, any number of Logical Volumes (LV) are then carved out, which behave like normal block devices and get formatted with a filesystem.

Internally, LVM works with so called Physical Extents, small, equally sized storage blocks (4 MiB by default) that make up the entire volume group. A logical volume consists of a certain number of these extents, which do not necessarily have to sit contiguously on disk. This indirection is exactly what makes growing, shrinking, and moving logical volumes possible while the system is running, without the application noticing anything.

3. Setting up LVM: pvcreate, vgcreate, lvcreate

Building an LVM structure always follows the same order: first the disk is initialized as a physical volume, then a volume group is formed from it, and only after that do the actual logical volumes get created. Before the first step, the disk or partition must be empty, LVM overwrites the beginning of the device with its own metadata during initialization.

# Initialize a raw disk as an LVM physical volume
sudo pvcreate /dev/sdb

# Create a volume group from one or more physical volumes
sudo vgcreate vg_data /dev/sdb

# Create a logical volume with a fixed size inside the volume group
sudo lvcreate -L 50G -n lv_mysql vg_data

# Create a logical volume that uses all remaining free space
sudo lvcreate -l 100%FREE -n lv_media vg_data

# Verify the resulting device path
ls -l /dev/vg_data/lv_mysql

After lvcreate, the logical volume is available as a block device at /dev/vg_data/lv_mysql, and in parallel a second, more stable path exists at /dev/mapper/vg_data-lv_mysql. Both paths point to the same device, but /etc/fstab should always reference the filesystem UUID rather than the device path, because device names can in theory change across reboots.

4. Creating a filesystem and mounting it permanently

A freshly created logical volume is initially just an empty block device, it needs a filesystem before any data can be written. Running mkfs.ext4 /dev/vg_data/lv_mysql or mkfs.xfs /dev/vg_data/lv_media creates the desired filesystem, the choice between ext4 and XFS depends on the use case, XFS often scales somewhat better with very large files and parallel write access. After that the volume can be mounted manually, but for permanent operation the entry belongs in /etc/fstab.

# /etc/fstab entry for an LVM logical volume, referenced by UUID
# Find the UUID first: blkid /dev/vg_data/lv_mysql

UUID=4f3a9c21-8b7e-4e2a-9d31-7a5c8e0f1a22  /var/lib/mysql  ext4  defaults,noatime  0  2
UUID=9a1e77d0-2c44-4b19-9e8a-1f6d3c5b7e90  /var/www/media  xfs   defaults,noatime  0  2

The noatime option prevents the access timestamp from being updated on every read, which noticeably reduces I/O load for database workloads. After any change to /etc/fstab, always test with sudo mount -a to check the file is syntactically correct before the next reboot, a typo in this file can otherwise cause the system to drop into emergency mode at boot.

5. Growing logical volumes online

The real value of LVM shows up when a logical volume needs to grow while the system stays in production. The prerequisite is free space in the associated volume group, either from unused extents or by adding another disk. The process happens in two steps: first the logical volume itself is grown, then the filesystem inside must be adjusted to the new size, both steps can be performed on ext4 and XFS without unmounting the filesystem.

# Extend the logical volume by 20 GiB
sudo lvextend -L +20G /dev/vg_data/lv_mysql

# Resize the ext4 filesystem to fill the new logical volume size
sudo resize2fs /dev/vg_data/lv_mysql

# For XFS, the filesystem must be mounted during the resize
sudo xfs_growfs /var/www/media

# Combine both steps for ext4 in a single command
sudo lvextend -r -L +20G /dev/vg_data/lv_mysql

Combining lvextend with the -r flag runs both steps automatically and detects on its own whether ext4 or XFS is in use. Important: LVM can technically shrink logical volumes too, but that is fundamentally impossible with XFS, XFS only supports growing a filesystem, never shrinking it. Anyone planning to possibly shrink a volume later should choose ext4 from the start.

6. Snapshots for consistent backups

LVM snapshots let you freeze the state of a logical volume at a specific point in time without interrupting production. Technically, LVM creates a new, usually much smaller logical volume that only stores the changes (copy on write) relative to the original. For backups this means: instead of blocking a running MySQL database during a dump, you create a snapshot, mount it separately, and back it up from there while the actual database keeps running.

# Create a snapshot with 5 GiB reserved for copy-on-write changes
sudo lvcreate -L 5G -s -n lv_mysql_snap /dev/vg_data/lv_mysql

# Mount the snapshot read-only for a consistent backup
sudo mkdir -p /mnt/snap
sudo mount -o ro /dev/vg_data/lv_mysql_snap /mnt/snap

# Run the backup against the frozen snapshot
sudo tar -czf /backup/mysql-$(date +%F).tar.gz -C /mnt/snap .

# Clean up after the backup completed
sudo umount /mnt/snap
sudo lvremove -f /dev/vg_data/lv_mysql_snap

A snapshot is not a replacement for a full backup, it lives in the same volume group as the original and is lost just as much in a total disk failure. It is also important to reserve enough space for copy on write changes, if that area fills up during the backup, the snapshot automatically becomes invalid. For databases with heavy write load, a snapshot should therefore be created, backed up, and removed again quickly.

7. Extending the volume group with new disks

If storage needs grow beyond the capacity of the existing volume group, another physical disk can simply be added. To do this, the new disk is first initialized as a physical volume with pvcreate and then assigned to the existing volume group with vgextend. From that moment on, the additional storage is available for new or existing logical volumes, without ever stopping the application.

One downside of this flexibility: if a logical volume spans multiple physical disks, its reliability depends on every single disk, if one of them fails, the entire volume can be damaged. For production systems, LVM is therefore often combined with RAID as an underlying layer, RAID provides redundancy at the block level, LVM on top provides flexible allocation of the resulting storage. pvmove also allows moving data between disks while the system is running, for example to remove an old disk from the volume group.

8. Monitoring and troubleshooting

Getting an overview of existing LVM structures is done with three commands, each showing one of the three layers: pvs for physical volumes, vgs for volume groups, and lvs for logical volumes. All three commands provide compact tables with size, free space, and assignment. For more detailed information, such as the exact extent distribution of a logical volume, lvdisplay provides a more detailed view.

# Overview of all three LVM layers
sudo pvs   # physical volumes: size, free space, VG assignment
sudo vgs   # volume groups: total size, free extents
sudo lvs   # logical volumes: size, attached volume group

# Detailed view of a single logical volume
sudo lvdisplay /dev/vg_data/lv_mysql

# Common troubleshooting: duplicate PV UUID after disk clone
sudo pvscan --cache
sudo vgimportclone --basevgname vg_data_clone /dev/sdc

A typical problem in practice arises when a disk is cloned via dd or as a VM snapshot: LVM detects two identical physical volumes based on the UUID and may refuse access to avoid data corruption. vgimportclone solves this by assigning new, unique UUIDs to the cloned volume group and its physical volumes. Anyone working with LVM regularly should also integrate pvs, vgs, and lvs into their own monitoring tooling to catch capacity bottlenecks early.

9. LVM in direct comparison

Whether LVM, a classic partition, or RAID is the right choice depends on the specific use case. The following overview shows the most important differences in practice.

In practice, LVM costs one extra step during initial setup but earns that effort back many times over with every resize while running. Only when absolute simplicity or maximum performance without any indirection layer is required, for example on very small, immutable systems, is skipping LVM worth it.

10. Summary

LVM turns rigid partitions into a flexible storage pool, from which logical volumes can be carved out, grown, and secured with snapshots as needed. The three core concepts, physical volume, volume group, and logical volume, build on each other and together form the abstraction layer that production Linux servers today can hardly do without.

Planning for LVM from the start saves later migrations to a more flexible setup. The combination of online growth, snapshots for backups, and the ability to add more disks to a volume group at any time makes LVM a standard tool for both database and media directories.

11. FAQ: Using LVM Logical Volumes in Practice