LVM Backup Best Practices

Most Linux server distributions deploy storage through the Logical Volume Manager (LVM). LVM abstracts physical disks into flexible virtual partitions, but this abstraction changes what a backup agent must read to produce a consistent, restorable image. Selecting the wrong layer results in backups that cannot be restored.

This guide explains which LVM layer StateWarden protects, how consistent snapshots and change tracking behave on LVM volumes, and what to consider when restoring or rebuilding a system from scratch.

1. LVM Layers and the Logical Volume Rule

LVM organizes storage into three layers:

1. Physical Volumes (PV): The underlying disks or partitions consumed by LVM (for example /dev/sda2, shown by tools such as lsblk with the type LVM2_member).
2. Volume Groups (VG): A pool of storage capacity aggregated from one or more PVs.
3. Logical Volumes (LV): The virtual partitions carved out of a VG, where filesystems and data actually live (for example /dev/vg0/root or /dev/mapper/vg0-data).

Always select the Logical Volume as the backup source. An LV is a regular block device with a stable boundary: it has a filesystem, a defined size, and can be snapshotted. In the Dashboard's device storage view, PVs appear as de-emphasized pool member entries and are not offered as individual backup targets; the LVs layered on top of them are the selectable devices.

Backing up a single LV (such as data) also allows it to be restored independently, without touching other LVs (such as root) in the same VG.

2. Why Physical Volumes Are Not Valid Backup Targets

Reading a PV directly (for example imaging /dev/sda2) does not produce a usable backup:

• No consistent point in time. A raw PV read captures sectors while the system is writing to them. LVM metadata headers and filesystem data may be caught mid-update, and the result may not be recoverable. A PV cannot be snapshotted on its own.
• Incomplete data on multi-disk groups. If a VG spans or stripes across several PVs, a single PV holds only fragments of each LV. Reconstructing the VG would require all PVs captured at exactly the same instant, which is not possible on a running system.
• No per-volume restore. A PV image mixes the extents of every LV in the VG, so individual volumes cannot be restored selectively.

3. Consistent Backups with LVM Snapshots

StateWarden uses the native LVM snapshot mechanism to achieve crash-consistent backups of logical volumes:

1. Before reading the volume, the Agent creates a temporary LVM snapshot of the source LV. A snapshot presents a frozen, point-in-time view of the volume; LVM redirects subsequent writes on the origin using copy-on-write, so the snapshot content does not change while the backup runs.
2. The Agent reads the backup data from the snapshot device instead of the live origin. Databases and files are captured exactly as they were at the snapshot instant, even if the backup itself takes a long time.
3. When the job finishes, the temporary snapshot is removed.

Operational notes:

• Classic LVM snapshots consume space in the VG as the origin changes during the backup window. Keep enough free extents in the VG to absorb the expected write volume for the duration of a backup; a snapshot that runs out of space becomes invalid and the backup fails.
• Application-level consistency is a separate concern. For databases, use their native flush or quiesce hooks where applicable; the LVM snapshot guarantees a crash-consistent image, not an application-quiesced one.

4. CBT Behavior on LVM Volumes

On plain partitions, Smart CBT accelerates incremental backups by tracking changed blocks between runs. LVM logical volumes behave differently: LVM provides native snapshot mechanisms that the Agent uses to identify changed data, so applying the separate CBT wrapper to an LV is unnecessary.

Accordingly, the CBT toggle in the Dashboard's device storage view reports the following tooltip for LVM volumes:

LVM uses native snapshots. CBT wrapper not required.

This is informational, not an error. Incremental backups of LVM volumes still run; change detection is simply provided through LVM's own snapshot mechanisms rather than through the wrapper used for plain partitions. For background on how Smart CBT works on other volume types, see Smart CBT: Incremental Backups and Smart NTFS and Block-Level Backups.

5. Thin-Provisioned Volumes

LVM thin provisioning allocates capacity on demand from a thin pool instead of pre-assigning it to each volume. Thin LVs are backed up like any other logical volume, but keep the following in mind:

• Snapshot space comes from the thin pool. Snapshots of thin volumes consume pool capacity as data is written during the backup window. Monitor pool utilization and keep headroom; an exhausted thin pool can affect the origin volumes, not only the snapshot.
• Virtual size vs. real data. A thin LV can present a virtual size far larger than the pool's physical capacity. Restore targets are sized against the LV's virtual size (see Section 6), so plan target storage accordingly when moving a thin volume to different hardware.

6. What to Exclude

Not every block device in an LVM system is worth protecting:

• Snapshot volumes. Do not add LVM snapshot devices (whether StateWarden's temporary snapshots or manually created ones) as backup sources. A snapshot's copy-on-write content is transient and duplicative; backing up snapshots of snapshots wastes storage and produces images with no independent restore value. Back up the origin LV instead.
• Swap volumes. Swap contains only transient memory pages with no value after a reboot. Swap devices are excluded from change tracking and should not be assigned to a backup policy. A swap LV is recreated trivially during a rebuild.

7. Restore Considerations

LVM volumes are restored at the block level, which imposes sizing rules on the target:

• Same size or larger. The target LV must be at least as large as the source LV was at backup time. Restoring a block-level image onto a smaller LV is not possible; create the target LV with sufficient size before starting the restore.
• Grow the filesystem afterwards. When restoring onto a larger LV, the restored filesystem retains its original size. Grow it after the restore to use the additional space (for example xfs_growfs for XFS or resize2fs for ext4, according to the filesystem type).
• Recreate LVM before restoring onto fresh setups. If the target machine does not yet have the required VG and LV layout, create it first with the standard LVM tools (pvcreate, vgcreate, lvcreate), then restore the volume contents into the new LVs.

8. Bare Metal Recovery on LVM-Based Systems

Protecting logical volumes rather than physical disks does not prevent full-system recovery onto blank hardware. Smart BMR records the storage layout of the protected system along with the volume data. During a bare metal restore, the recovery environment:

1. Boots the target machine from the StateWarden Recovery ISO.
2. Presents the available empty physical disks for selection.
3. Recreates the LVM structure (physical volumes, volume groups, and logical volumes) from the layout information stored with the backup.
4. Restores the backed-up data into the newly created LVs and applies the bootloader fixups required to make the system bootable.

The full procedure, including recovery media preparation and token generation, is described in the Bare Metal Recovery Walkthrough.

Summary Checklist