How to Create and Manage LVM Snapshots and Volumes on Ubuntu Server

Deploying production systems on Ubuntu Server requires robust storage architecture that can adapt to changing capacity needs without downtime. Logical Volume Manager (LVM) abstracts physical hard drives and solid-state storage into flexible virtual partitions. Beyond dynamic volume resizing and spanning across multiple disks, one of LVM’s most vital capabilities is LVM Snapshots. Snapshots freeze the exact block-level state of a logical volume at a specific point in time, enabling point-in-time backups, fearless system updates, and instantaneous rollbacks if software deployments fail.

How LVM Architecture and Snapshots Function

LVM organizes storage across three distinct abstraction layers:

• Physical Volumes (PV): Raw block devices, disk partitions, or RAID arrays (e.g., /dev/sdb1 or /dev/nvme0n1) initialized for LVM.
• Volume Groups (VG): Storage pools constructed by grouping one or more Physical Volumes together.
• Logical Volumes (LV): Virtual partitions carved out of a Volume Group and formatted with file systems (such as ext4 or xfs).

When you create an LVM snapshot, LVM does not copy the entire volume’s contents immediately. Instead, it utilizes a Copy-on-Write (CoW) mechanism. The snapshot allocates a modest portion of free space in the Volume Group. When data on the original volume is altered, the original blocks are copied to the snapshot storage first. Unchanged blocks remain read directly from the origin volume, creating near-instantaneous backups with minimal storage overhead.

Prerequisites for Using LVM on Ubuntu Server

Verify that your Ubuntu Server installation utilizes LVM by inspecting existing volumes:

sudo pvs
sudo vgs
sudo lvs

To create a snapshot, your Volume Group must possess unallocated free space. Run sudo vgs and inspect the VFree column. If your Volume Group has zero free space, you will need to resize an existing volume down or add an additional physical disk to the group first.

How to Create an LVM Snapshot on Ubuntu

Suppose you have a logical volume named lv_data residing within the volume group vg_ubuntu mounted at /var/www. To take a point-in-time snapshot before running a risky database migration:

sudo lvcreate --size 5G --snapshot --name lv_data_snap /dev/vg_ubuntu/lv_data

In this command:

• --size 5G: Specifies the maximum Copy-on-Write space reserved for modifications. If changes on the original volume exceed 5GB while the snapshot exists, the snapshot will overflow and become invalid.
• --snapshot (or -s): Instructs LVM to establish a point-in-time CoW copy.
• --name lv_data_snap: Assigns a clear name to the snapshot.
• /dev/vg_ubuntu/lv_data: Points to the origin source volume.

Verify the snapshot’s creation and inspect its usage:

sudo lvs

The output displays the snapshot alongside an Allocated % metric (e.g., 0.02%), which increases as data on the origin volume changes.

How to Mount and Inspect Snapshot Data

Unlike traditional static disk images, an LVM snapshot can be mounted directly into the Linux file system as a read-only or read-write partition to inspect historical files or perform consistent backups without taking applications offline:

sudo mkdir -p /mnt/snapshot
sudo mount -o ro /dev/vg_ubuntu/lv_data_snap /mnt/snapshot

Note for XFS filesystems: Because XFS identifies volumes via unique UUIDs, mount XFS snapshots with the nouuid flag: sudo mount -o nouuid,ro /dev/vg_ubuntu/lv_data_snap /mnt/snapshot.

You can now copy files, run tar archives, or feed backup daemons from /mnt/snapshot while your production services continue writing to the origin volume.

Rolling Back to an LVM Snapshot

If a package upgrade or software update corrupts your original volume, you can revert all block changes back to the exact instant the snapshot was captured:

1. Unmount the production volume (if it is a non-root data partition):

   sudo umount /var/www

2. Merge the snapshot back into the origin volume:

   sudo lvconvert --merge /dev/vg_ubuntu/lv_data_snap

3. LVM will merge modified blocks back into place. For unmounted data partitions, the merge completes immediately.
4. Remount the restored volume:

   sudo mount /dev/vg_ubuntu/lv_data /var/www

If you are merging a snapshot of the root filesystem (/), LVM will schedule the merge to execute automatically during the next system reboot before root services initialize.

Deleting an LVM Snapshot

Because snapshots accumulate Copy-on-Write blocks over time and consume I/O performance during write operations, they should be deleted once backups complete or system updates prove stable:

sudo umount /mnt/snapshot
sudo lvremove /dev/vg_ubuntu/lv_data_snap

Confirm the deletion prompt with y. The reserved storage space is immediately returned to your Volume Group’s free pool.

Frequently Asked Questions

What happens if an LVM snapshot runs out of allocated space?

If changes to the origin volume exceed the snapshot’s configured size, the snapshot becomes corrupted (status marked as INACTIVE) and can no longer be read or merged. You can monitor usage with lvs or configure auto-extension in /etc/lvm/lvm.conf using snapshot_autoextend_threshold.

Can I create a snapshot while the server is actively running?

Yes. LVM snapshots are designed specifically for live production systems. For transactional databases like MySQL or PostgreSQL, consider briefly locking tables or taking an LVM snapshot during quiet periods to ensure application-level consistency.

Do LVM snapshots replace offsite backups?

No. An LVM snapshot relies entirely on the underlying physical disks of the Volume Group. If a physical disk fails, both the origin volume and its snapshot will be lost. Use snapshots as temporary staging points to extract consistent offsite backups.