Undo any change: snapshots of your home folder with snapper

Level BeginnerEstimated time 20 minA word you don't know? Glossary

Before editing a configuration file, people copy it to .bak. A month later the home folder holds forty of them, nobody knows which one is good, and some sit in places where they get executed by mistake. If your system uses the btrfs file system (Fedora, openSUSE, CachyOS and many others do by default), there is a better way: snapshots.

A snapshot is a photo of a folder at an instant, taken in a second and costing only what changes afterwards. Take one before touching anything; if the change goes wrong, bring the file back from the photo.

A bit of history

btrfs was started in 2007 by Chris Mason, then at Oracle, as a modern Linux file system built on copy-on-write: data is never overwritten in place, so a snapshot of the whole disk costs almost nothing and takes a second. snapper, developed at SUSE, schedules those snapshots and takes one before and after each system change.

1. A configuration for your home folder

Snapper manages btrfs snapshots. Create a configuration for /home, allow your user to use it without sudo, and keep a reasonable history:

sudo snapper -c home create-config /home
sudo snapper -c home set-config ALLOW_USERS=$USER SYNC_ACL=yes \
     TIMELINE_CREATE=yes TIMELINE_LIMIT_DAILY=7 TIMELINE_LIMIT_WEEKLY=2

Then make sure both timers run: one takes the hourly snapshots, the other deletes the old ones.

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

2. Before a risky change

snapper -c home create -d "before editing ssh config"

One second, no copy. The command prints nothing; snapper -c home list shows the snapshot and its number.

3. Undo

See what changed since snapshot 42, then bring one file back:

snapper -c home status 42..0
snapper -c home undochange 42..0 $HOME/.ssh/config

Or simply read the old version: every snapshot is a normal folder, /home/.snapshots/42/snapshot/.

Traps we paid for

If the cleanup timer is not running, snapshots pile up forever. Ours had collected more than 800; deleted files kept their space because old snapshots still held them. Enabling the cleanup gave back more than 200 GB at once.

Do not leave Docker's data inside a snapshotted volume. Every snapshot keeps the images you delete, so removing a 160 GB model store freed 5 GB. Give /var/lib/docker its own btrfs subvolume, which snapshots skip.

Large model files belong in a folder that is not snapshotted, for the same reason: a 40 GB download you delete should come back as free space, not stay in a snapshot for two weeks.

Sources

Found this useful? Tell us what to measure next.