{"id":165233,"date":"2026-04-03T20:15:15","date_gmt":"2026-04-03T17:15:15","guid":{"rendered":"https:\/\/computingforgeeks.com\/?p=165233"},"modified":"2026-04-03T20:15:15","modified_gmt":"2026-04-03T17:15:15","slug":"btrfs-snapshots-snapper-automatic-rollback-fedora-opensuse","status":"publish","type":"post","link":"https:\/\/computingforgeeks.com\/btrfs-snapshots-snapper-automatic-rollback-fedora-opensuse\/","title":{"rendered":"Btrfs Snapshots with Snapper: Automatic System Rollback on Fedora and openSUSE"},"content":{"rendered":"\n

A bad dnf update<\/code> can leave your Fedora system in a state where packages conflict, services refuse to start, or the kernel panics on boot. If your root filesystem is Btrfs, you can undo the entire transaction in seconds. Snapper creates copy-on-write snapshots before and after every package operation, and grub-btrfs lets you boot directly into any of those snapshots if the system won’t come up at all.<\/p>\n\n\n\n

This guide covers the full setup: configuring Snapper for automatic pre\/post snapshots on Fedora 42, wiring it into DNF5 with the actions plugin, installing grub-btrfs so snapshots appear in the GRUB menu, and testing a real rollback by removing a package and restoring it. There’s also a comparison with openSUSE, which ships all of this out of the box. If you’re looking for a different backup strategy, see our guide on immutable backups with Restic and Borg<\/a>.<\/p>\n\n\n\n

Tested April 2026 on Fedora 42 (Cloud Edition, kernel 6.14.0-63.fc42.x86_64) with Snapper 0.11.0 and grub-btrfs 4.13<\/em><\/p>\n\n\n\n

How Btrfs Snapshots Differ from LVM Snapshots<\/h2>\n\n\n\n

Both Btrfs and LVM can snapshot a filesystem, but the implementations are fundamentally different. Btrfs snapshots are metadata-only operations that complete instantly regardless of volume size. LVM snapshots allocate a separate COW device that degrades write performance proportionally to snapshot age. If you’re currently using LVM snapshots for backups, our LVM snapshot guide<\/a> covers that workflow.<\/p>\n\n\n\n

Feature<\/th>Btrfs Snapshots<\/th>LVM Snapshots<\/th><\/tr><\/thead>
Creation time<\/td>Instant (metadata-only)<\/td>Fast but requires COW device allocation<\/td><\/tr>
Performance impact<\/td>Negligible<\/td>Write penalty increases with snapshot age<\/td><\/tr>
Space usage<\/td>Shared blocks, grows only as data changes<\/td>Fixed-size COW device, overflows kill the snapshot<\/td><\/tr>
Rollback method<\/td>snapper undochange<\/code> or boot into snapshot<\/td>lvconvert –merge (requires reboot)<\/td><\/tr>
Number of snapshots<\/td>Hundreds with minimal overhead<\/td>Each snapshot needs its own COW device<\/td><\/tr>
Granularity<\/td>Per-subvolume<\/td>Per-logical-volume<\/td><\/tr>
Built into filesystem<\/td>Yes<\/td>No (block-level, filesystem unaware)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The practical advantage is that you can keep dozens of Btrfs snapshots with almost no performance cost, which makes automatic pre\/post snapshots on every DNF transaction viable.<\/p>\n\n\n\n

Fedora 42 Default Btrfs Layout<\/h2>\n\n\n\n

Fedora has shipped Btrfs as the default filesystem since Fedora 33. The installer creates three subvolumes on the root partition, each mounted at a different path. Understanding this layout matters because Snapper operates on subvolumes, not mount points.<\/p>\n\n\n\n

List the existing subvolumes:<\/p>\n\n\n\n

sudo btrfs subvolume list \/<\/code><\/pre>\n\n\n\n
Fedora 42 creates three subvolumes by default:<\/p>\n\n\n\n
ID 256 gen 21 top level 5 path root\nID 257 gen 14 top level 5 path home\nID 258 gen 22 top level 5 path var<\/code><\/pre>\n\n\n\n
Check how they’re mounted:<\/p>\n\n\n\n
mount | grep btrfs<\/code><\/pre>\n\n\n\n
Each subvolume is mounted with compression and async discard enabled:<\/p>\n\n\n\n
\/dev\/vda4 on \/ type btrfs (rw,relatime,seclabel,compress=zstd:1,discard=async,space_cache=v2,subvolid=256,subvol=\/root)\n\/dev\/vda4 on \/home type btrfs (rw,relatime,seclabel,compress=zstd:1,discard=async,space_cache=v2,subvolid=257,subvol=\/home)\n\/dev\/vda4 on \/var type btrfs (rw,relatime,seclabel,compress=zstd:1,discard=async,space_cache=v2,subvolid=258,subvol=\/var)<\/code><\/pre>\n\n\n\n
The root<\/code> subvolume (ID 256) holds \/<\/code>, which is where DNF installs packages. That’s the subvolume we’ll configure Snapper to snapshot. The home<\/code> subvolume gets its own config for user data protection.<\/p>\n\n\n\n
Install and Configure Snapper<\/h2>\n\n\n\n
Snapper is in the default Fedora repos. Install it along with the DNF5 actions plugin, which we’ll need later for automatic pre\/post snapshots:<\/p>\n\n\n\n
sudo dnf install -y snapper libdnf5-plugin-actions<\/code><\/pre>\n\n\n\n
Create a Snapper configuration for the root subvolume:<\/p>\n\n\n\n
sudo snapper -c root create-config \/<\/code><\/pre>\n\n\n\n
This creates the \/.snapshots<\/code> directory and a new Snapper config file at \/etc\/snapper\/configs\/root<\/code>. Do the same for \/home<\/code> if you want user data snapshots:<\/p>\n\n\n\n
sudo snapper -c home create-config \/home<\/code><\/pre>\n\n\n\n
Verify both configs exist:<\/p>\n\n\n\n
sudo snapper list-configs<\/code><\/pre>\n\n\n\n
Both subvolumes should appear:<\/p>\n\n\n\n
Config \u2502 Subvolume\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nhome   \u2502 \/home\nroot   \u2502 \/<\/code><\/pre>\n\n\n\n
Enable Timeline Snapshots<\/h3>\n\n\n\n
Timeline snapshots are hourly automatic snapshots that Snapper creates and cleans up based on retention rules. Enable them for the root config:<\/p>\n\n\n\n
sudo systemctl enable --now snapper-timeline.timer\nsudo systemctl enable --now snapper-cleanup.timer<\/code><\/pre>\n\n\n\n
The timeline timer creates snapshots, and the cleanup timer deletes old ones according to the retention policy.<\/p>\n\n\n\n
Set Retention Limits<\/h3>\n\n\n\n
The default retention is generous to a fault. On a server with limited disk, tighten it. Edit the root config:<\/p>\n\n\n\n
sudo vi \/etc\/snapper\/configs\/root<\/code><\/pre>\n\n\n\n
Set these values (adjust to your disk size):<\/p>\n\n\n\n
TIMELINE_CREATE=yes\nTIMELINE_CLEANUP=yes\nTIMELINE_LIMIT_HOURLY=5\nTIMELINE_LIMIT_DAILY=7\nTIMELINE_LIMIT_WEEKLY=0\nTIMELINE_LIMIT_MONTHLY=0\nSPACE_LIMIT=0.5\nFREE_LIMIT=0.2\nNUMBER_CLEANUP=yes\nNUMBER_LIMIT=50<\/code><\/pre>\n\n\n\n
SPACE_LIMIT=0.5<\/code> means Snapper will delete snapshots if they consume more than 50% of the filesystem. FREE_LIMIT=0.2<\/code> triggers cleanup when free space drops below 20%. NUMBER_LIMIT=50<\/code> caps the total number of numbered snapshots (the pre\/post type that DNF creates). These limits prevent snapshots from silently filling your disk.<\/p>\n\n\n\n
SELinux Context for Snapshots<\/h3>\n\n\n\n
Fedora runs SELinux in enforcing mode. Snapper’s .snapshots<\/code> directory needs the correct context, or restoring files from snapshots may fail with permission denied errors. The context is usually inherited correctly, but verify it:<\/p>\n\n\n\n
ls -Zd \/.snapshots<\/code><\/pre>\n\n\n\n
The context should show system_u:object_r:snapperd_data_t:s0<\/code>. If it shows unlabeled_t<\/code> instead, restore it:<\/p>\n\n\n\n
sudo restorecon -rv \/.snapshots<\/code><\/pre>\n\n\n\n
Take a manual test snapshot to confirm everything works:<\/p>\n\n\n\n
sudo snapper -c root create -d \"Manual test snapshot\"<\/code><\/pre>\n\n\n\n
List snapshots to see it:<\/p>\n\n\n\n
sudo snapper -c root list<\/code><\/pre>\n\n\n\n
Snapshot #1 should appear with your description and the current timestamp.<\/p>\n\n\n\n
DNF5 Pre\/Post Snapshots with the Actions Plugin<\/h2>\n\n\n\n
On openSUSE, zypper talks to Snapper natively. On Fedora, the old python3-dnf-plugin-snapper<\/code> broke when Fedora 41 switched from DNF4 to DNF5. The replacement is the libdnf5-plugin-actions<\/code> package, which lets you hook shell commands into DNF5 transaction events.<\/p>\n\n\n\n
Create the actions file:<\/p>\n\n\n\n
sudo vi \/etc\/dnf\/libdnf5-plugins\/actions.d\/snapper.actions<\/code><\/pre>\n\n\n\n
Add the following content:<\/p>\n\n\n\n
pre_transaction::::\/usr\/bin\/sh -c echo\\ \"tmp.cmd=$(ps\\ -o\\ command\\ --no-headers\\ -p\\ '${pid}')\"\npre_transaction::::\/usr\/bin\/sh -c echo\\ \"tmp.snapper_pre=$(snapper\\ -c\\ root\\ create\\ -c\\ number\\ -t\\ pre\\ -p\\ -d\\ '${tmp.cmd}')\"\npost_transaction::::\/usr\/bin\/sh -c [\\ -n\\ \"${tmp.snapper_pre}\"\\ ]\\ &&\\ snapper\\ -c\\ root\\ create\\ -c\\ number\\ -t\\ post\\ --pre-number\\ \"${tmp.snapper_pre}\"\\ -d\\ \"${tmp.cmd}\"<\/code><\/pre>\n\n\n\n
The first line captures the DNF command that triggered the transaction. The second creates a pre-transaction snapshot and stores its number. The third line runs after the transaction completes and creates the matching post snapshot, linking it to the pre snapshot number. The -c number<\/code> flag marks both snapshots for the number cleanup algorithm.<\/p>\n\n\n\n
Test it by installing a package:<\/p>\n\n\n\n
sudo dnf install -y htop<\/code><\/pre>\n\n\n\n
Check whether Snapper captured the transaction:<\/p>\n\n\n\n
sudo snapper -c root list<\/code><\/pre>\n\n\n\n
The pre\/post pair should appear with the exact DNF command as the description:<\/p>\n\n\n\n
 # \u2502 Type   \u2502 Pre # \u2502 Date                            \u2502 User \u2502 Cleanup \u2502 Description          \u2502 Userdata\n\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n0 \u2502 single \u2502       \u2502                                 \u2502 root \u2502         \u2502 current              \u2502\n1 \u2502 single \u2502       \u2502 Fri 03 Apr 2026 04:20:23 PM UTC \u2502 root \u2502         \u2502 Manual test snapshot \u2502\n2 \u2502 pre    \u2502       \u2502 Fri 03 Apr 2026 04:21:05 PM UTC \u2502 root \u2502 number  \u2502 dnf install -y htop  \u2502\n3 \u2502 post   \u2502     2 \u2502 Fri 03 Apr 2026 04:21:05 PM UTC \u2502 root \u2502 number  \u2502 dnf install -y htop  \u2502<\/code><\/pre>\n\n\n\n
Snapshot #2 is the pre (filesystem state before htop was installed), and #3 is the post (state after). The Pre #<\/code> column on #3 links it to #2, so Snapper knows they’re a pair.<\/p>\n\n\n\n
Install grub-btrfs for Snapshot Boot<\/h2>\n\n\n\n
Rolling back from a running system with snapper undochange<\/code> works well for package removals and config changes. But if a kernel update breaks boot entirely, you need to select a snapshot from the GRUB menu before the system even starts. That’s what grub-btrfs provides.<\/p>\n\n\n\n
grub-btrfs is not in the Fedora repos, so build it from source. Install the build dependencies first:<\/p>\n\n\n\n
sudo dnf install -y git make<\/code><\/pre>\n\n\n\n
Clone the repository and install:<\/p>\n\n\n\n
git clone https:\/\/github.com\/Antynea\/grub-btrfs.git\ncd grub-btrfs\nsudo make install<\/code><\/pre>\n\n\n\n
Fedora uses grub2-mkconfig<\/code> instead of grub-mkconfig<\/code>, and the GRUB directory is \/boot\/grub2<\/code> instead of \/boot\/grub<\/code>. Configure grub-btrfs for Fedora’s layout:<\/p>\n\n\n\n
sudo vi \/etc\/default\/grub-btrfs\/config<\/code><\/pre>\n\n\n\n
Set these three variables:<\/p>\n\n\n\n
GRUB_BTRFS_GRUB_DIRNAME=\"\/boot\/grub2\"\nGRUB_BTRFS_MKCONFIG=\/usr\/sbin\/grub2-mkconfig\nGRUB_BTRFS_SCRIPT_CHECK=grub2-script-check<\/code><\/pre>\n\n\n\n
Regenerate the GRUB configuration:<\/p>\n\n\n\n
sudo grub2-mkconfig -o \/boot\/grub2\/grub.cfg<\/code><\/pre>\n\n\n\n
The output should list every snapshot it found:<\/p>\n\n\n\n
Found snapshot: 2026-04-03 16:21:57 | root\/.snapshots\/5\/snapshot | post   | dnf install -y git make |\nFound snapshot: 2026-04-03 16:21:55 | root\/.snapshots\/4\/snapshot | pre    | dnf install -y git make |\nFound snapshot: 2026-04-03 16:21:05 | root\/.snapshots\/3\/snapshot | post   | dnf install -y htop     |\nFound 5 snapshot(s)<\/code><\/pre>\n\n\n\n
On reboot, a new “Fedora Linux snapshots” submenu appears in GRUB. Each snapshot is listed with its date and description. Selecting one boots a read-only view of the filesystem at that point in time, which is useful for recovering files or verifying what changed.<\/p>\n\n\n\n
Enable the grub-btrfs daemon so new snapshots are automatically added to GRUB without running grub2-mkconfig<\/code> manually each time:<\/p>\n\n\n\n
sudo systemctl enable --now grub-btrfsd<\/code><\/pre>\n\n\n\n
The daemon watches \/.snapshots<\/code> for changes and regenerates the GRUB submenu automatically.<\/p>\n\n\n\n
Break Something and Roll It Back<\/h2>\n\n\n\n
The real test of any snapshot system is recovering from damage. We’ll remove bash-completion<\/code> (a package that deletes over a thousand files) and then undo the change using Snapper.<\/p>\n\n\n\n
Remove the package:<\/p>\n\n\n\n
sudo dnf remove -y bash-completion<\/code><\/pre>\n\n\n\n
The actions plugin creates snapshots #6 (pre) and #7 (post) automatically:<\/p>\n\n\n\n
sudo snapper -c root list<\/code><\/pre>\n\n\n\n
The new pair appears at the bottom:<\/p>\n\n\n\n
6 \u2502 pre    \u2502       \u2502 Fri 03 Apr 2026 04:26:30 PM UTC \u2502 root \u2502 number  \u2502 dnf remove -y bash-completion \u2502\n7 \u2502 post   \u2502     6 \u2502 Fri 03 Apr 2026 04:26:30 PM UTC \u2502 root \u2502 number  \u2502 dnf remove -y bash-completion \u2502<\/code><\/pre>\n\n\n\n
See exactly what changed between the pre and post snapshots:<\/p>\n\n\n\n
sudo snapper status 6..7<\/code><\/pre>\n\n\n\n
Snapper shows every file that was deleted, modified, or created. The -.....<\/code> prefix means deleted:<\/p>\n\n\n\n
-..... \/etc\/bash_completion.d\/000_bash_completion_compat.bash\n-..... \/etc\/profile.d\/bash_completion.sh\nc..... \/usr\/lib\/sysimage\/libdnf5\/nevras.toml<\/code><\/pre>\n\n\n\n
The full list is much longer (over a thousand deleted files). Now restore the pre-removal state:<\/p>\n\n\n\n
sudo snapper undochange 6..7<\/code><\/pre>\n\n\n\n
Snapper restores every deleted file and reverts every modification:<\/p>\n\n\n\n
create:1051 modify:8 delete:0<\/code><\/pre>\n\n\n\n
1,051 files recreated, 8 files reverted to their pre-removal state. The bash-completion package is back, and all its files are in place. No reboot required, no package manager involved. This is the power of filesystem-level rollback: it doesn’t care what removed the files or why. It just restores the snapshot.<\/p>\n\n\n\n
One caveat: snapper undochange<\/code> restores files on disk, but the RPM database still thinks the package is removed. Run dnf reinstall -y bash-completion<\/code> afterward to sync the package manager’s state with reality. This is a Fedora-specific limitation because unlike openSUSE, the RPM database lives on a separate subvolume.<\/p>\n\n\n\n
openSUSE: How It Compares<\/h2>\n\n\n\n
openSUSE Tumbleweed and Leap have had Snapper integration since 2012. If you’re choosing between Fedora and openSUSE specifically for snapshot rollback, the differences are worth knowing.<\/p>\n\n\n\n
Capability<\/th>Fedora 42<\/th>openSUSE Tumbleweed\/Leap<\/th><\/tr><\/thead>
Snapper pre-installed<\/td>No (dnf install required)<\/td>Yes, configured out of the box<\/td><\/tr>
Package manager integration<\/td>Manual (actions plugin file)<\/td>Native zypper integration<\/td><\/tr>
GRUB snapshot boot<\/td>grub-btrfs from source<\/td>Built into grub2-snapper-plugin<\/td><\/tr>
Rollback command<\/td>snapper undochange<\/code><\/td>snapper rollback<\/code> (full subvolume swap)<\/td><\/tr>
RPM database in snapshot<\/td>No (lives in \/var, separate subvolume)<\/td>Yes (included in root snapshot)<\/td><\/tr>
Boot into snapshot + make permanent<\/td>Manual process<\/td>snapper rollback<\/code> sets new default boot<\/td><\/tr>
YaST Snapper module<\/td>N\/A<\/td>GUI for browsing and restoring snapshots<\/td><\/tr>
Default subvolume layout<\/td>3 subvolumes (root, home, var)<\/td>20+ subvolumes for granular control<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The biggest difference is rollback depth. On openSUSE, snapper rollback<\/code> performs a true subvolume swap: it makes the snapshot the new default root and reboots into it. The RPM database, the kernel, everything rolls back together because they’re all in the same snapshot. On Fedora, snapper undochange<\/code> is a file-level restore that doesn’t touch the bootloader or RPM database. Both approaches work, but openSUSE’s is more integrated.<\/p>\n\n\n\n
That said, Fedora’s approach gives you more flexibility. You can selectively undo specific transactions without reverting everything that happened after them, which is useful when only one DNF operation caused problems.<\/p>\n\n\n\n
Snapshot Space Management<\/h2>\n\n\n\n
Snapshots are cheap to create but expensive to keep. Every file modification after a snapshot is taken means the old data block is preserved instead of being freed. Over weeks, this adds up.<\/p>\n\n\n\n
Snapper’s Cleanup Algorithms<\/h3>\n\n\n\n
Snapper has three cleanup algorithms that run via the snapper-cleanup.timer<\/code>:<\/p>\n\n\n\n