Snapper on OpenSUSE: Fine‑Tuned Btrfs Snapshots for Safe Package Updates

Why Snapper Matters on OpenSUSE

When you run zypper to install or upgrade packages on a Btrfs‑mounted root filesystem, a single failed transaction can leave the system in an inconsistent state. Snapper gives you a safety net by automatically taking read‑only snapshots before and after each transaction. If something goes wrong, you can roll back to a clean snapshot with a single command.

Understanding the Snapper Configuration

The core configuration lives in /etc/snapper/configs/root. A minimal file looks like this:

# Snapper configuration for the root filesystem
config_type = btrfs
# Create a snapshot before and after every zypper transaction
create_before = yes
create_after = yes
# Keep only the latest 10 snapshots for the timeline
timeline_limit = 10
# Keep only the latest 5 snapshots created by zypper
number_limit = 5
# Use snapshot names that include the date and a short hash
# (helps identify the snapshot later)
name_format = %Y-%m-%d-%H-%M-%S

Key points:

• config_type tells Snapper which filesystem type it should work with – here btrfs.
• create_before/after enable automatic snapshots around zypper commands.
• timeline_limit and number_limit are retention policies that prevent the snapshot directory from growing indefinitely.
• name_format controls the human‑readable snapshot name.

Practical Example: Installing a Package Safely

1. Open a terminal as root or use sudo.
2. Verify the current snapshot list:

   snapper list

   This shows all snapshots in /.snapshots/root.
3. Install a package with zypper:

   sudo zypper install htop

   Because create_before and create_after are enabled, Snapper will automatically create two snapshots: one just before the transaction and one just after.
4. Check the new snapshots:

   snapper list | tail -2

   You should see entries labeled before-install and after-install.
5. If the new package caused a crash or unwanted configuration change, roll back:

   sudo snapper rollback 42

   Replace 42 with the snapshot ID of the before-install snapshot. The system will revert to the state captured in that snapshot.

Pruning Old Snapshots Safely

Without pruning, the /.snapshots directory can fill up the Btrfs quota and degrade performance. Snapper offers a built‑in prune command:

sudo snapper -c root prune

This command applies the limits defined in /etc/snapper/configs/root and removes snapshots that exceed those limits. It is safe because Snapper only deletes read‑only snapshots; the root filesystem remains untouched.

Automating Prune with a Timer

OpenSUSE ships a systemd timer that runs snapper prune weekly. Verify it is active:

systemctl status snapper-cleanup.timer

If it is not enabled, enable it with:

sudo systemctl enable --now snapper-cleanup.timer

Trade‑Offs and Limitations

• Storage Overhead: Each snapshot consumes space proportional to the amount of changed data. On a busy system, snapshots can add up quickly. Use timeline_limit and number_limit to keep the number of snapshots manageable.
• Performance Impact: While snapshot creation is fast, the additional metadata can slightly increase the overhead of file operations, especially on very large filesystems.
• Read‑Only Snapshots: Snapper cannot modify snapshots. If you need to edit a snapshot, you must first clone it, which creates another snapshot.
• Root Filesystem Only: The example above configures Snapper for the root filesystem. To protect other Btrfs subvolumes, create separate configs under /etc/snapper/configs/ for each subvolume.

Actionable Checklist

1. Confirm your root is on Btrfs. Run df -T / | grep btrfs.
2. Install Snapper if not already present: sudo zypper install snapper.
3. Edit /etc/snapper/configs/root to enable create_before and create_after.
4. Test a package install and verify snapshots appear with snapper list.
5. Run sudo snapper -c root prune to ensure pruning works.
6. Enable snapper-cleanup.timer for automatic weekly pruning.
7. Document the snapshot strategy in your system maintenance plan.

Conclusion

Snapper turns Btrfs snapshots into a practical safety net for OpenSUSE users. By configuring automatic snapshots around zypper transactions, setting sensible retention limits, and automating pruning, you can recover from problematic updates with minimal effort. The trade‑offs—storage overhead and slight performance impact—are manageable with proper limits. With Snapper in place, your OpenSUSE system gains a robust, low‑maintenance rollback mechanism that keeps you from spending hours troubleshooting broken packages.