Create and Roll Back Linux System Snapshots with snapm

snapm (Snapshot Manager) groups snapshots of one or more volumes into a single snapshot set you can boot, inspect, or revert as a unit. On Enterprise Linux 10, it pairs with the Boom Boot Manager to publish GRUB menu entries for snapshot boot and failsafe revert — a practical way to test updates or roll back a failed change without rebuilding the host.

This walkthrough uses LVM2 on Rocky Linux 10.2. The same commands apply on RHEL 10, AlmaLinux 10, and Oracle Linux 10 where snapm and boom-boot ship in AppStream and your root file system sits on supported storage.

Understand snapm snapshot sets and rollback

A snapshot set is a named collection of volume snapshots captured at one point in time. When you snapshot / and /var together, both mount points reflect the same moment — useful before a distribution update or a risky package change.

Booting the Snapshot entry is temporary inspection. The changed origin volumes still exist underneath. Revert is the destructive path: it merges the snapshot data into the origin and removes the snapshot set.

If /var is a separate LVM volume and you include it in the set, revert rolls back everything stored there — logs, Podman storage, libvirt images, and database files under /var. Plan mount points deliberately.

Check whether the storage layout supports snapm

snapm needs supported storage under each mount point you include. This lab uses LVM thin provisioning; thick LVM copy-on-write snapshots use the lvm2-cow plugin instead.

Inspect mounts and volume layout:

findmnt -o TARGET,SOURCE,FSTYPE / /var

Sample output when only / is on LVM (no separate /var):

TARGET SOURCE           FSTYPE
/      /dev/mapper/rlm-root xfs

List logical volumes and free space in the volume group:

sudo lvs -a

Sample output:

LV              VG  Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00          rlm twi-aotz-- 14.00g               85.33  35.89
  [pool00_tdata]  rlm Twi-ao---- 14.00g
  [pool00_tmeta]  rlm ewi-ao---- 16.00m
  root            rlm Vwi-aotz-- 14.00g pool00        85.33

Check volume-group free extents:

sudo vgs

Sample output:

VG  #PV #LV #SN Attr   VSize  VFree
  rlm   1   2   0 wz--n- 17.54g 3.51g

Confirm the block layout with lsblk -f when you need to distinguish LVM from plain partitions.

Do not continue if / is not on LVM2 or Stratis. Plain partition layouts, Btrfs root, and unsupported volume types belong in a different workflow.

Ensure the VM has console or GRUB access before you create bootable snapshot sets.

Install Snapshot Manager and Boom

Install the packages from AppStream:

sudo dnf install snapm boom-boot

Verify versions:

rpm -q snapm boom-boot

Sample output:

snapm-0.7.0-2.el10.noarch
boom-boot-1.6.8-1.el10.noarch

Check the snapm release and registered storage plugins:

snapm --version
snapm plugin list

Sample output:

0.7.0
PluginName PluginVersion PluginType       Priority
lvm2-cow   0.2.0         Lvm2CowSnapshot        10
lvm2-thin  0.2.0         Lvm2ThinSnapshot       15

Stratis appears only when the Stratis D-Bus service is available. snapm selects the highest-priority plugin that matches your volume layout — here lvm2-thin for a thin-provisioned root logical volume.

List Boom profiles:

boom profile list

On a fresh Rocky Linux 10.2 install this table can be empty until snapm or you create a profile. If boot entry creation fails later, create one manually:

sudo boom profile create --from-host \
  --uname-pattern '.*el10.*' \
  -n 'Rocky Linux' -s rocky

Sample output:

Created profile with os_id e8f5536:
  Name: "Rocky Linux", Short name: "rocky",
  Version: "10.2 (Red Quartz)", Version ID: "10.2",
  UTS release pattern: ".*el10.*"

Plan snapshot capacity

Snapshot space policy matters more on busy thin pools than on thick volumes with dedicated snapshot areas.

Check file-system use and pool headroom:

df -h / /var
sudo vgs
sudo lvs -a -o lv_name,origin,lv_size,data_percent,metadata_percent

Common size policies for snapm snapset create and snapm snapset resize:

No single policy fits every host. On a thin pool that is already above 80% data utilization, percentage-based policies may fail with insufficient pool space — use a modest fixed size for lab testing, or extend the thin pool before production snapshots.

Create a bootable snapshot set

Confirm the exact flags on your package:

snapm snapset create --help

On snapm 0.7.0 the boot flag is --bootable (some distribution docs abbreviate this as --boot). Pair it with --revert so snapm also registers a Revert GRUB entry.

When / and /var are separate LVM mount points:

sudo snapm snapset create \
  --bootable \
  --revert \
  --size-policy 200%USED \
  before-change / /var

When only / is on LVM (this lab layout):

sudo snapm snapset create \
  --bootable \
  --revert \
  --size-policy 1G \
  before-change /

The fixed 1G policy succeeded on a thin pool that rejected 200%USED with insufficient free space. Adjust the policy for your volume group and change window.

Sample output:

SnapsetName:      before-change
Sources:          /
NrSnapshots:      1
Time:             2026-07-22 21:21:24
Status:           Active
Bootable:         yes
BootEntries:
  SnapshotEntry:  220e501
  RevertEntry:    cfa090e

Key fields:

• SnapsetName — identifier for list, show, revert, resize, and delete
• Sources — mount points included in the set
• NrSnapshots — number of volume snapshots in the set
• Bootable — whether a Snapshot GRUB entry was created
• BootEntries — Boom entry IDs for Snapshot and Revert paths

List snapshots and verify Boom boot entries

Inspect the snapshot set:

sudo snapm snapset list
sudo snapm snapset show before-change
sudo snapm snapshot list

Sample snapm snapshot list output:

SnapsetName   Name                                        Origin           Source  Status  Size    Free   Autoactivate Provider
before-change rlm/root-snapset_before-change_1784735484_- /dev/rlm/root    /       Active  14.0GiB 2.0GiB yes          lvm2-thin

List Boom entries by title:

sudo boom list -o+title

Sample output:

BootID  Version                           Name        RootDevice                                       Title
7cba8e1 6.12.0-211.16.1.el10_2.0.1.x86_64 Rocky Linux /dev/mapper/rlm-root                             Rocky Linux (6.12.0-211.16.1.el10_2.0.1.x86_64) 10.2 (Red Quartz)
220e501 6.12.0-211.16.1.el10_2.0.1.x86_64 Rocky Linux /dev/mapper/rlm-root-snapset_before-change_... Snapshot before-change 2026-07-22 21:21:24 (6.12.0-211.16.1.el10_2.0.1.x86_64)
cfa090e 6.12.0-211.16.1.el10_2.0.1.x86_64 Rocky Linux /dev/mapper/rlm-root                             Revert before-change 2026-07-22 21:21:24 (6.12.0-211.16.1.el10_2.0.1.x86_64)

Confirm both Snapshot and Revert titles exist. Do not edit generated Boom or Boot Loader Specification files by hand — use snapm and boom subcommands.

Inspect underlying LVM snapshots:

sudo lvs -a

The snapshot logical volume appears with an Origin column pointing at root.

Make and verify a controlled system change

After the snapshot set exists, make visible, safe changes you can verify later:

echo "System changed after snapm snapshot" | sudo tee /etc/snapm-test.conf

Install a small package:

sudo dnf install -y tree

Record the post-snapshot state:

cat /etc/snapm-test.conf
rpm -q tree

Sample output:

System changed after snapm snapshot
tree-2.1.0-8.el10.x86_64

Avoid intentionally breaking GRUB, LVM, networking, SSH, or authentication in this first walkthrough.

Boot into and inspect the snapshot

Reboot and choose the Snapshot before-change … entry from the GRUB menu. Alternatively, pre-select that entry for the next boot only:

sudo grub2-reboot "Snapshot before-change 2026-07-22 21:21:24 (6.12.0-211.16.1.el10_2.0.1.x86_64)"
sudo reboot

Use the exact title from sudo boom list -o+title on your host — timestamps and kernel versions differ.

After the snapshot boot completes, confirm which device backs /:

findmnt /
sudo snapm snapset show before-change

You should see:

• /etc/snapm-test.conf does not exist
• tree is not installed
• findmnt shows a device name containing the snapset snapshot suffix

Snapshot boot is inspection only. The origin volumes still hold your changes until you run a revert merge.

Reboot back to the normal Rocky Linux entry when you finish inspecting, or proceed to revert if you are ready to roll back.

Revert the complete snapshot set

Initiate revert from the snapshot boot environment:

sudo snapm snapset revert before-change

snapm schedules the merge because the origin volumes are active in the running system. Reboot and select the Revert before-change … GRUB entry. Do not interrupt the merge.

After the revert boot completes, verify the rolled-back state:

findmnt /
test ! -e /etc/snapm-test.conf && echo "test file absent"
rpm -q tree
sudo lvs -a
sudo snapm snapset list

You should see:

• Configuration and package changes made after the snapshot are gone
• Snapshot logical volumes merged or removed
• Snapshot and Revert Boom entries cleaned up when the set completes

Reverting destroys the snapshot set by merging it into the origin. Treat it as irreversible for the changes made after the snapshot timestamp.

Monitor snapshot space and prevent failure

Monitor through snapm:

sudo snapm snapshot list -o name,size,free

Sample output:

Name                                        Size    Free
rlm/root-snapset_before-change_1784735484_- 14.0GiB 1.9GiB

Also watch the thin pool or thick snapshot area in LVM:

sudo lvs -a -o lv_name,origin,lv_size,data_percent,metadata_percent
sudo vgs

Grow a snapshot set before it fills:

sudo snapm snapset resize before-change /:300%USED

If resize fails with insufficient pool space, extend the thin pool or volume group with normal LVM tools (extend an LVM partition) before the snapshot fills.

Delete snapshot sets and clean up boot entries

When the system change succeeded and you no longer need rollback, delete the set from the running system:

sudo snapm snapset delete before-change

Deleting the snapshot set removes associated Snapshot and Revert boot entries.

Verify cleanup:

sudo snapm snapset list
sudo snapm snapshot list
sudo boom list -o+title
sudo lvs -a

Scheduled retention exists for automation-focused follow-up articles:

snapm schedule list

This guide stops at listing schedules — creating policies and garbage collection belong in a dedicated retention article.

Troubleshoot snapm and rollback failures

Diagnostic commands:

sudo snapm -vv snapset show before-change
sudo lvs -a
sudo vgs
sudo boom list -o+title
sudo journalctl -b
sudo journalctl --priority err

References

• Red Hat Enterprise Linux 10 — Managing system upgrades with snapshots
• snapm User Guide
• snapm command reference
• Boom Boot Manager documentation
• Red Hat Enterprise Linux 10 — Creating and mounting LVM snapshots