Btrfs subvolumes decide what your snapshots can save

“Can I just turn on automatic snapshots and be safe?”

Not quite. On a Btrfs desktop, snapshots are useful local recovery points, but they are not a substitute for backups, and they do not magically cover everything under a mount point. The practical question comes before Snapper, before a timer, and before any rollback button: which parts of your filesystem are in the subvolume being snapshotted, and which parts are separated on purpose?

Btrfs calls a subvolume a part of the filesystem with its own file and directory hierarchy and its own inode number namespace. It looks like a directory in day-to-day use, but it has extra filesystem meaning. A snapshot is also a subvolume, created with the initial contents of another subvolume. Btrfs documentation is blunt about the risk: a snapshot is not a backup. Because snapshots rely on copy-on-write behavior, the original and the snapshot initially share data blocks. If the underlying data is damaged, both can be damaged.

That distinction matters on a workstation. A snapshot can help you recover from a bad package transaction, a mistaken configuration edit, or a desktop change you regret. It does not protect you from disk loss, theft, controller failure, or a write that damages the storage both states share. For that, you still need a backup that leaves the machine, the disk, or at least the filesystem failure domain.

The second distinction is less obvious: Btrfs snapshots are not recursive across subvolume boundaries. If one subvolume contains another, snapshotting the outer one does not include the files inside the nested subvolume. The Btrfs docs describe the nested subvolume as a barrier. In the snapshot, you get an empty stub with the same name, not the nested subvolume’s contents.

This is not a bug. It is the design decision that makes a sane desktop rollback possible.

Imagine a root filesystem where everything lives inside one subvolume. If you snapshot it before an upgrade and roll back after trouble, you may get a simple system restore. But you may also roll back logs, local databases, virtual machine images, downloaded work, and other data that should not move backward just because a package update did. The upstream Btrfs page uses that exact system-root case to explain why directories that should survive rollback are often made separate subvolumes.

Now invert the mistake. If you expected `/home` or a VM directory to be protected by root snapshots, but your installer or your own layout made it a separate subvolume, the root snapshot will not contain those files. Snapper may have done exactly what it was told. The layout told it where the boundary was.

Snapper adds policy around this. Its configuration files describe a Snapper config, including the `SUBVOLUME` path or mount point and the filesystem type. It can create timeline snapshots, and its cleanup settings decide how many hourly, daily, monthly, and yearly snapshots to keep, with the youngest snapshots kept in each category. It also has space-aware cleanup settings for Btrfs, including a maximum snapshot space threshold and a minimum free-space threshold. Those are retention rules. They do not change what the selected subvolume contains.

So the useful pre-flight check is not “are snapshots enabled?” It is “what do I want rollback to mean?”

For a desktop system, the answer is usually narrower than the whole disk. System files should be recoverable after a bad upgrade. Some state should persist across that rollback: logs, caches, databases, containers, VM images, and personal files, depending on how the machine is used. Personal files may deserve their own snapshot policy, but that is different from tying them to root rollback. A notebook used for local AI experiments may also have model caches and generated outputs that should not silently vanish because the operating system returned to yesterday’s state.

This is where product defaults matter. Shadowfetch Linux is our own Debian/KDE desktop, so its recovery story has to be readable by the person sitting at the machine, not only by the person who designed the image; the same principle applies if you are building from another distribution’s installer or reviewing our install notes before putting it on hardware. A local recovery feature is only honest if the included and excluded paths are understandable.

The safest mental model is simple. A Btrfs subvolume is the unit Snapper can target. A Btrfs snapshot is a local point-in-time view of that unit. A nested or separate subvolume is a line the snapshot will not cross. Cleanup settings decide how long old points remain. Backups decide whether the data survives the machine.

Before enabling automatic timeline snapshots, write down three lists: what must roll back with the system, what must survive a system rollback, and what must be backed up elsewhere no matter how many snapshots exist. Then make the subvolume layout and Snapper configs match those lists.

A snapshot can save the state it actually contains; the hard part is deciding, before trouble starts, what state that should be.

Disclosure: This article was drafted with AI assistance under human editorial direction. The linked Linux project is a Shadowfetch product.