The nightmare scenario has a script: run a big update, reboot, meet a broken desktop. On most filesystems the fix involves live USBs and an evening of surgery. On Btrfs with snapshots configured, it is “boot the snapshot from before the update, roll back, done.” That capability is arguably the single best reason Btrfs is the default on openSUSE, Fedora, and Linux Mint’s recommended layouts, and tools like Timeshift make it automatic.

Why Btrfs snapshots are effectively free

Btrfs is a copy-on-write filesystem: modifying a file writes new blocks and updates metadata to point at them, rather than overwriting in place. A snapshot exploits this directly. It is a new subvolume whose metadata points at all the same blocks as the original, created in a fraction of a second regardless of size. At the moment of creation it consumes almost nothing; space is only consumed as the original diverges, block by block, from the snapshot. Keeping a week of daily snapshots of a system that changes a few hundred megabytes a day costs a few gigabytes, not seven copies of your disk.

Snapshots operate on subvolumes, Btrfs’s internal sub-filesystems, which is why distro installers create a layout like @ for root and @home for home directories: separate subvolumes mean you can snapshot and roll back the system without touching your files, or vice versa.

Manual snapshots in two commands

The plumbing is simple enough to use bare:

# Snapshot the root subvolume (path depends on layout)
sudo btrfs subvolume snapshot / /.snapshots/root-$(date +%F)

# List subvolumes and snapshots
sudo btrfs subvolume list /

# Read-only snapshot (required for btrfs send)
sudo btrfs subvolume snapshot -r /home /.snapshots/home-$(date +%F)

# Delete one
sudo btrfs subvolume delete /.snapshots/root-2026-08-01

A snapshot mounts and browses like any directory, so recovering one file is a cp away. But nobody should be running these by hand on a schedule; that is what the automation layer is for.

Timeshift: the friendly automation

Timeshift, Linux Mint’s system-restore tool, automates the whole lifecycle in Btrfs mode: scheduled snapshots (hourly, daily, weekly, boot), retention pruning, and one-click restore from GUI or CLI:

sudo timeshift --create --comments "before nvidia driver"
sudo timeshift --list
sudo timeshift --restore

Timeshift deliberately scopes itself to system restore: by default it excludes home directories, on the sound theory that rolling back a bad update should not also roll back today’s documents. It expects the common @/@home subvolume layout, which Mint and Ubuntu’s Btrfs installs provide.

Restoring flips the subvolume: Timeshift renames the snapshot into place as the new @ and keeps the broken state as its own snapshot, so a restore is itself undoable after the next boot.

Snapper: the thorough automation

Snapper, openSUSE’s equivalent, goes further: integrated with the package manager, it takes paired pre/post snapshots around every package operation, so each install or update brackets itself with before and after states:

sudo snapper list
sudo snapper -v undochange 42..43   # revert what operation 42->43 changed

On openSUSE this plugs into grub via grub-btrfs style integration out of the box: the boot menu lists snapshots, so a broken system is fixed by selecting the pre-update snapshot at boot and running snapper rollback. That boot-menu integration is available on other distros too via the grub-btrfs package plus a Snapper or Timeshift hook, and it is the piece that turns snapshots from a recovery tool into an actual undo button.

Choosing between them: Timeshift for simplicity and Mint-style desktops, Snapper for package-aware granularity and openSUSE-style integration. Both beat manual snapshots by remembering to run.

The line snapshots do not cross

A snapshot lives on the same physical disk as the data it protects, sharing most blocks with it. Drive dies, snapshots die too; same for theft, fire, and filesystem-level corruption. Snapshots answer “the software state was better yesterday”; they are silent on “the hardware is gone.” Btrfs itself offers the bridge: btrfs send streams a read-only snapshot to another disk or machine (btrfs send | btrfs receive), and tools like btrbk automate incremental send-based replication. That, or a conventional backup tool running alongside, is the other half of the safety story: snapshots for rollback, backups for survival. Configured together, a Btrfs system offers a level of recoverability that genuinely changes how casually you can run updates.

Frequently Asked Questions

What is a Btrfs snapshot?

A copy of a subvolume at a moment in time, created instantly. Thanks to copy-on-write, the snapshot shares all data with the original and only consumes space as the two diverge, so keeping many snapshots is cheap.

Are snapshots backups?

No. Snapshots live on the same disk as the data and die with it. They protect against bad updates, mistakes, and unwanted changes, not against drive failure. Send snapshots to another disk, or run separate backups, for real protection.

What is the difference between Timeshift and Snapper?

Both automate Btrfs snapshots. Timeshift is simpler, focused on system files with a friendly GUI, and is the Linux Mint default. Snapper is more configurable, snapshots on every package operation with pre and post pairs, and is standard on openSUSE.

Do snapshots slow down my system?

Keeping a reasonable number of snapshots has negligible performance impact. Very large snapshot counts can slow filesystem maintenance operations, which is why automated tools prune old snapshots on a schedule.

Can I boot into a snapshot if an update breaks my system?

On distros set up for it, yes: grub-btrfs adds snapshots to the boot menu, and openSUSE ships this integration out of the box. Otherwise you boot normally or from live media and restore the snapshot, then reboot.

Why does my ext4 system not have snapshots?

ext4 has no native snapshot support. Snapshotting needs copy-on-write filesystems like Btrfs or ZFS, or LVM underneath ext4, which can snapshot at the volume layer with more setup and overhead.