How to Set Up Automated Btrfs Snapshots on Ubuntu Desktop

Ubuntu Desktop's 26.04 LTS installation guide lists its standard and advanced disk setup options but does not list Btrfs as an installer choice. It was last updated on May 6, 2026. That means a Btrfs Ubuntu desktop may use a custom partition or subvolume layout. Before automating snapshots, identify what is actually mounted at /; a Snapper command that assumes a Btrfs root subvolume can fail or protect the wrong data. This guide sets up hourly timeline snapshots with Snapper on a verified Btrfs subvolume, then enables scheduled cleanup so old snapshots do not accumulate forever.

Snapper is available in Ubuntu's repositories, and Ubuntu 26.04 LTS (Resolute) packages include systemd units for its timeline and cleanup jobs. The exact commands below are for a machine whose intended snapshot target is a Btrfs subvolume. If your Ubuntu installation uses ext4, LVM, or a Btrfs top-level mount rather than the subvolume you intend to protect, stop at the layout check and resolve that first.

What does a Btrfs snapshot protect?

A Btrfs snapshot is a point-in-time subvolume that initially shares file extents with its source. It is useful for recovering files or comparing system states after a mistaken edit or update. It is not an independent backup: the snapshot remains on the same filesystem, so disk failure, filesystem damage, theft, or accidental deletion of the whole filesystem can take both the live data and snapshots with it.

Snapshots also do not recursively capture nested subvolumes. If /home is a separate subvolume, a snapshot of the root subvolume does not include the contents of that separate /home. Plan one Snapper configuration for each subvolume you need to protect, or rely on a separate backup for user data. Keep a second copy on another device or remote system for disaster recovery.

1. Confirm that Ubuntu is running on Btrfs

Open Terminal and inspect the root mount:

findmnt -no SOURCE,FSTYPE,OPTIONS /
sudo btrfs subvolume show /
sudo btrfs subvolume list /

The first command should report btrfs as the filesystem type. Review the mount options for a subvol= entry and use the subvolume listing to understand the layout. The second command should identify the subvolume mounted at /. If the filesystem type is not Btrfs, this Snapper procedure is not applicable. If the command reports that / is not a subvolume, or shows that it is the top-level subvolume, do not try to create a root Snapper config blindly. Btrfs's top-level subvolume has special limitations; use a correctly designed subvolume layout or snapshot a verified separate subvolume instead.

Check separately whether /home is a mount point or subvolume with findmnt /home and sudo btrfs subvolume show /home. If it is separate and you want snapshots of personal files, it needs its own configuration. Also consider whether other important paths, such as a separate data mount, live on another filesystem. A root snapshot will not include them automatically.

2. Install Snapper and the Btrfs tools

Once you have confirmed the target is a Btrfs subvolume, install the Ubuntu packages:

sudo apt update
sudo apt install snapper btrfs-progs

snapper manages snapshot configurations and retention; btrfs-progs provides filesystem utilities useful for inspecting Btrfs. Check for configurations that already exist before creating another one:

sudo snapper list-configs

If a configuration named root already points to the correct root subvolume, keep it and review its settings instead of creating a duplicate. If the output is empty and / has been verified as the subvolume you intend to protect, create the configuration:

sudo snapper -c root create-config /

The create-config command creates the Snapper configuration and its snapshot directory for the selected subvolume. If it reports that the configuration already exists or that the path is not a subvolume, stop and inspect the current setup; do not delete an existing configuration to force the command through.

3. Choose a snapshot schedule and retention policy

Snapper's timeline mode can create hourly snapshots and its timeline cleanup algorithm can retain selected hourly, daily, weekly, monthly, and yearly snapshots. For a desktop with limited free space, start with a modest policy and monitor storage rather than keeping an unlimited history. This example requests six hourly, seven daily, four weekly, and three monthly snapshots, with no yearly snapshots:

sudo snapper -c root set-config 'TIMELINE_CREATE=yes TIMELINE_CLEANUP=yes TIMELINE_LIMIT_HOURLY=6 TIMELINE_LIMIT_DAILY=7 TIMELINE_LIMIT_WEEKLY=4 TIMELINE_LIMIT_MONTHLY=3 TIMELINE_LIMIT_YEARLY=0'

These values describe retention categories; they are not a hard limit on disk space. A changed or deleted large file can keep old data extents allocated for as long as snapshots reference them. Available space also depends on other Btrfs subvolumes and files. Check df -h / and sudo btrfs filesystem usage / periodically, and reduce retention or add storage if the filesystem is getting full. Avoid editing several configs at once: run sudo snapper -c root get-config and verify the values after changing them.

4. Enable Snapper's systemd timers

On Ubuntu 26.04 LTS, the Snapper package file list includes snapper-timeline.timer and snapper-cleanup.timer. Enable both so systemd periodically creates timeline snapshots and runs cleanup:

sudo systemctl enable --now snapper-timeline.timer snapper-cleanup.timer

Check that they are loaded and see when they are next scheduled:

systemctl list-timers snapper-timeline.timer snapper-cleanup.timer
systemctl status snapper-timeline.timer snapper-cleanup.timer

A timer showing as active means systemd has the schedule loaded; it does not by itself prove that Snapper successfully created a snapshot. After the next timeline run, check the configuration and snapshot list:

sudo snapper list-configs
sudo snapper -c root list

If no timeline snapshot appears after the scheduled run, confirm that TIMELINE_CREATE is set to yes, then inspect the service log with journalctl -u snapper-timeline.service -b. Do not create a custom timer until you have checked the packaged units and logs; duplicate schedules can create more snapshots than intended.

5. Add a separate configuration for a Btrfs home subvolume

Only do this if your layout check confirmed that /home is itself a Btrfs subvolume and your goal includes user files. First run sudo snapper list-configs and make sure the name home is unused. Then create a config for that subvolume and apply a separate retention policy:

sudo snapper -c home create-config /home
sudo snapper -c home set-config 'TIMELINE_CREATE=yes TIMELINE_CLEANUP=yes TIMELINE_LIMIT_HOURLY=6 TIMELINE_LIMIT_DAILY=7 TIMELINE_LIMIT_WEEKLY=4 TIMELINE_LIMIT_MONTHLY=3 TIMELINE_LIMIT_YEARLY=0'

The same systemd timers process Snapper configurations that have timeline creation and cleanup enabled, so a separate timer is normally unnecessary. Confirm that sudo snapper -c home list works and that sudo snapper -c home get-config shows the intended values. A directory named /home is not automatically a separate subvolume; verify it before running create-config.

How do you know automation is working?

• Configuration: sudo snapper list-configs shows the intended name and subvolume.
• Policy: sudo snapper -c root get-config reports timeline creation and cleanup enabled.
• Schedule: systemctl list-timers shows the two Snapper timers and their next run times.
• Snapshots: sudo snapper -c root list shows dated entries after the timer has run.
• Service health: journalctl -u snapper-timeline.service -b contains no recurring errors preventing snapshot creation.

If your computer is shut down at a scheduled time, a timer may run later depending on its unit settings; it is not a substitute for checking the resulting snapshots. A small manual test can verify that Snapper can create a snapshot: run sudo snapper -c root create --description 'setup test', then list snapshots again. This tests the configuration, not the timer; remove the test snapshot later only if you are sure you selected the correct entry.

What can go wrong, and what should you avoid?

First, snapshots consume shared filesystem capacity over time. Retention controls reduce old history, but the amount of retained data varies with file changes. Monitor free space and make sure cleanup is running. Second, a root snapshot may omit nested subvolumes such as /home; a successful command does not mean every mounted path is protected. Third, Snapper snapshots alone do not guarantee a bootable rollback. Snapper documents rollback as requiring a properly configured Btrfs system. Ubuntu's mount layout, boot configuration, encryption, and separate filesystems determine what recovery is possible. Before relying on rollback, test a recovery plan with a separate backup and recovery media.

Do not treat automatic snapshots as a replacement for backups. Copy important files to another physical device or remote location, and periodically confirm that you can restore those files. For the most dependable Ubuntu desktop setup, use Snapper for convenient local restore points, a separate backup tool for independent copies, and a tested recovery procedure for system-level failures.

Official references

• Ubuntu Desktop: Advanced disk setup features
• Ubuntu 26.04 LTS Snapper manual
• Ubuntu 26.04 LTS Snapper package file list
• Btrfs documentation: Subvolumes and snapshots