thelinuxvault blog

LVM Backup and Restore: A Comprehensive Guide to Snapshots in Linux

In the world of Linux system administration, data integrity and recoverability are paramount. Whether you’re managing a personal server or a enterprise-grade infrastructure, the ability to back up critical data and restore it efficiently can mean the difference between a minor hiccup and a catastrophic outage. Logical Volume Management (LVM) is a powerful tool that simplifies storage management in Linux, and one of its most valuable features is snapshots.

LVM snapshots are lightweight, point-in-time copies of logical volumes (LVs) that enable quick backups and restores. Unlike full backups, which duplicate entire volumes, snapshots use a “copy-on-write” (CoW) mechanism to minimize storage overhead, making them ideal for frequent, short-term backups. In this blog, we’ll dive deep into LVM snapshots: how they work, how to create them, restore data from them, and best practices to ensure your backups are reliable.

2026-02

Table of Contents#

  1. Introduction to LVM and Snapshots
  2. Prerequisites
  3. Understanding LVM Snapshot Basics
  4. Step-by-Step: Creating an LVM Snapshot
  5. Step-by-Step: Restoring from an LVM Snapshot
  6. Advanced Snapshot Management
  7. Best Practices for LVM Snapshots
  8. Troubleshooting Common Snapshot Issues
  9. Conclusion
  10. References

Introduction to LVM and Snapshots#

Before diving into snapshots, let’s recap LVM basics. LVM abstracts physical storage (hard drives, SSDs) into Physical Volumes (PVs), which are grouped into Volume Groups (VGs). From VGs, you create Logical Volumes (LVs)—virtual “disks” that can be formatted, mounted, and used like traditional partitions.

An LVM snapshot is a special type of LV that captures the state of an existing LV (the “origin LV”) at a specific point in time. Unlike full backups, snapshots do not immediately copy all data from the origin LV. Instead, they use a copy-on-write (CoW) mechanism:

  • Initially, the snapshot shares the same data blocks as the origin LV.
  • When data on the origin LV is modified, the old version of the block is copied to the snapshot before the origin is updated.
  • This ensures the snapshot always reflects the origin’s state at the time of creation, while using minimal additional storage.

Prerequisites#

To follow this guide, ensure you have:

  • A Linux system with LVM2 installed (most modern distributions include it by default; install with sudo apt install lvm2 or sudo dnf install lvm2 if missing).
  • An existing LVM setup with at least one VG and one LV (the origin LV you want to back up).
  • Sufficient free space in the VG to create snapshots (we’ll discuss sizing later).
  • Root or sudo access to run LVM commands.

Verify Your LVM Setup#

Before proceeding, confirm your LVM configuration with these commands:

# List physical volumes (PVs)
sudo pvdisplay
 
# List volume groups (VGs) and free space
sudo vgdisplay
 
# List logical volumes (LVs)
sudo lvdisplay

Example output for vgdisplay might show:

  --- Volume group ---
  VG Name               vg_data
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  5
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <20.00 GiB
  PE Size               4.00 MiB
  Total PE              4991
  Alloc PE / Size       2560 / 10.00 GiB
  Free  PE / Size       2431 / <9.50 GiB  # Free space for snapshots
  VG UUID               abc123...

Note the Free PE / Size—this is the space available in the VG for creating snapshots.

Understanding LVM Snapshot Basics#

Key Snapshot Properties#

  • Read-Only vs. Read-Write: Snapshots are read-only by default, but can be created as read-write (useful for testing changes without affecting the origin LV).
  • Size: Snapshots require a fixed size allocated from the VG. This size determines how much “changed data” they can store before becoming invalid.
  • Lifetime: Snapshots are temporary. They should be used immediately for backups or testing and deleted afterward to free space.

How Copy-on-Write (CoW) Works#

Imagine you have an origin LV with 10GB of data, and you create a 2GB snapshot. Initially, the snapshot uses almost no space—it references the origin’s data blocks. When you modify a 100MB file on the origin LV:

  1. The snapshot copies the original 100MB of the file into its own allocated space.
  2. The origin LV then writes the new 100MB data.

The snapshot now uses 100MB of its 2GB space. If changes exceed 2GB, the snapshot becomes “invalid” (it can no longer track changes) and must be deleted.

Step-by-Step: Creating an LVM Snapshot#

Let’s create a snapshot for an origin LV named lv_data in volume group vg_data, mounted at /mnt/data.

Step 1: Choose a Snapshot Size#

Snapshot size depends on how much data you expect to change on the origin LV before you use the snapshot. A good rule of thumb:

  • For LVs with low change rates (e.g., static files), 10-15% of the origin LV size.
  • For high change rates (e.g., databases), 20-30% or more.

If the origin LV is 10GB and changes are minimal, we’ll use a 2GB snapshot.

Step 2: Create the Snapshot#

Use lvcreate with the --snapshot (or -s) flag:

sudo lvcreate -L 2G -s -n snap_lv_data /dev/vg_data/lv_data
  • -L 2G: Allocates 2GB of space for the snapshot.
  • -s: Marks this as a snapshot.
  • -n snap_lv_data: Names the snapshot snap_lv_data.
  • /dev/vg_data/lv_data: The origin LV to snapshot.

Step 3: Verify the Snapshot#

Check that the snapshot was created:

sudo lvdisplay /dev/vg_data/snap_lv_data

Example output:

  --- Logical volume ---
  LV Path                /dev/vg_data/snap_lv_data
  LV Name                snap_lv_data
  VG Name                vg_data
  LV UUID                def456...
  LV Write Access        read-only  # Default: read-only
  LV Creation host, time server, 2024-05-20 10:00:00
  LV snapshot status     active destination for lv_data
  LV Status              available
  # open                 0
  LV Size                10.00 GiB  # Matches origin LV size
  Current LE             2560
  COW-table size         2.00 GiB   # Snapshot's allocated space
  COW-table LE           512
  Allocated to snapshot  0.00%      # Initially, no space used
  Snapshot chunk size    4.00 KiB
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:3

The Allocated to snapshot field shows 0% usage initially—perfect!

Step-by-Step: Restoring from an LVM Snapshot#

Snapshots enable two common restore workflows: partial restore (recover specific files) and full restore (revert the entire origin LV to its snapshot state).

5.1 Restoring Specific Files (Partial Restore)#

If only a few files are corrupted or deleted, mount the snapshot and copy the files back.

Step 1: Mount the Snapshot#

Create a mount point and mount the read-only snapshot:

sudo mkdir /mnt/snap
sudo mount /dev/vg_data/snap_lv_data /mnt/snap -o ro  # -o ro enforces read-only

Step 2: Copy Files from the Snapshot#

List files in the snapshot to confirm:

ls -l /mnt/snap

Copy the missing/corrupted file (e.g., important.docx) back to the origin LV:

sudo cp /mnt/snap/important.docx /mnt/data/  # /mnt/data is the origin LV's mount point

Step 3: Unmount and Delete the Snapshot#

Once done, unmount and remove the snapshot to free space:

sudo umount /mnt/snap
sudo lvremove /dev/vg_data/snap_lv_data

Confirm deletion when prompted: Do you really want to remove and DISCARD logical volume vg_data/snap_lv_data? [y/n]: y

5.2 Full Restore: Merging the Snapshot with the Original LV#

If the entire origin LV is corrupted (e.g., after a failed upgrade), merge the snapshot back to revert the origin to its snapshot state.

Step 1: Unmount the Origin LV#

Critical: The origin LV must be unmounted during merging to avoid data corruption.

sudo umount /mnt/data

Step 2: Merge the Snapshot#

Use lvconvert --merge to merge the snapshot into the origin LV:

sudo lvconvert --merge /dev/vg_data/snap_lv_data

Example output:

  Merging of volume vg_data/snap_lv_data started.
  vg_data/lv_data: Merged: 100.00%

LVM automatically deletes the snapshot after merging.

Step 3: Remount the Origin LV#

Once merged, remount the origin LV:

sudo mount /dev/vg_data/lv_data /mnt/data

The origin LV now reflects the state captured in the snapshot!

Advanced Snapshot Management#

6.1 Resizing a Snapshot#

If a snapshot runs out of space (e.g., due to unexpected changes), resize it with lvextend:

# Check current usage
sudo lvs /dev/vg_data/snap_lv_data
 
# Extend the snapshot by 1GB (total size becomes 3GB)
sudo lvextend -L +1G /dev/vg_data/snap_lv_data

6.2 Deleting a Snapshot#

Always delete snapshots after use to free VG space:

sudo lvremove /dev/vg_data/snap_lv_data

6.3 Automating Snapshots with Cron#

For regular backups, automate snapshot creation with a cron job. Example: Daily snapshot of lv_data at 2 AM, kept for 1 day.

Create a script ~/lvm_snap.sh:

#!/bin/bash
# Create a timestamped snapshot
SNAP_NAME="snap_lv_data_$(date +%Y%m%d_%H%M%S)"
sudo lvcreate -L 2G -s -n $SNAP_NAME /dev/vg_data/lv_data
 
# Delete snapshots older than 1 day
sudo find /dev/vg_data -name "snap_lv_data_*" -mtime +1 -exec lvremove -f {} \;

Make it executable:

chmod +x ~/lvm_snap.sh

Add to crontab (run as root):

sudo crontab -e

Add this line:

0 2 * * * /home/user/lvm_snap.sh  # Runs daily at 2:00 AM

6.4 Read-Write Snapshots for Testing#

Create a read-write snapshot to test changes (e.g., software upgrades) without risking the origin LV:

sudo lvcreate -L 2G -s -n snap_test -r /dev/vg_data/lv_data  # -r = read-write

Mount and modify the snapshot:

sudo mount /dev/vg_data/snap_test /mnt/test
# Make changes (e.g., install software, edit files)
sudo umount /mnt/test

If tests pass, merge the snapshot (as in Section 5.2). If not, delete it:

sudo lvremove /dev/vg_data/snap_test

Best Practices for LVM Snapshots#

  1. Size Appropriately: Allocate 10-30% of the origin LV size, depending on change rates. Monitor usage with sudo lvs -o +snap_percent.
  2. Short Lifespan: Snapshots should live only as long as needed (hours/days, not weeks).
  3. Unmount Before Merging: Always unmount the origin LV to avoid corruption during merging.
  4. Test Restores: Regularly test restoring from snapshots to ensure they work when needed.
  5. Monitor Space: Use sudo vgdisplay to track free VG space and avoid filling it with snapshots.
  6. Avoid Nested Snapshots: Do not create snapshots of snapshots—this complicates management and increases overhead.

Troubleshooting Common Snapshot Issues#

Snapshot Is Full (“Invalid Snapshot”)#

Symptom: lvdisplay shows Snapshot status: invalid.
Cause: The snapshot ran out of space to store changed blocks.
Fix:

  • Delete the invalid snapshot: sudo lvremove -f /dev/vg_data/snap_lv_data.
  • Create a larger snapshot next time (e.g., 3GB instead of 2GB).

Merge Fails: “LV is open”#

Symptom: lvconvert --merge errors with “Logical volume vg_data/lv_data is open”.
Cause: The origin LV is still mounted.
Fix: Unmount the origin LV first: sudo umount /mnt/data.

“Not Enough Free Space” When Creating Snapshot#

Symptom: lvcreate fails with “Insufficient free space”.
Cause: The VG lacks free PE (physical extents).
Fix:

  • Extend the VG by adding a new PV: sudo vgextend vg_data /dev/sdb1 (replace /dev/sdb1 with a new disk/partition).
  • Reduce the snapshot size (not ideal, but a temporary fix).

Conclusion#

LVM snapshots are a game-changer for Linux backup and recovery. Their copy-on-write design makes them space-efficient, and their flexibility supports both partial and full restores. By following the steps in this guide—creating snapshots, restoring data, and managing them effectively—you can ensure your critical data is always recoverable.

Remember: The best backup strategy is one you test regularly. Practice creating and restoring snapshots to build confidence in your workflow!

References#