Snapper strategy for /home

I’m planning to use openSUSE as my daily driver and would like some advice on how people use Snapper for /home.

I got Tumbleweed running in a VM and played around with Snapper and rolling back the system. It works nicely, which made me think I probably want to use snapshots for /home as well. So, I ran snapper -c home create-config /home and everything still works nicely. I can roll back the system without rolling back /home and I can restore individual files in /home.

However, I think it’s probably a bad idea to let Snapper create regular snapshots of /home. Over time it will use lots of disk space and it’s probably overkill (for my use case at least).

I then figured it might make sense to to create snapshots of specific directories inside /home. For instance, I got a /home/$USER/dev directory which I use for several coding and documentation projects. I try to use git for those projects but I usually forget to create a new branch / commit changes, so having Snapper could be handy for those “that was not a good rabbit hole to go down to” moments.

So, my thinking is that I could do something like this:

# mv /home/example/home/dev /home/example/home/bk_dev
# btrfs subvolume create /home/example/home/dev
# snapper -c dev create-config /home/example/dev
# mv /home/example/bk_dev/* /home/example/dev/
# rmdir /home/example/bk_dev

Is that a sensible approach? Are there downsides I should be aware of?

If you only care about ~/dev then that’s fine. Although it would pay off if you get into the habit of making smaller commits often as it’s always possible to rewrite local history later.

A different approach to limit what’s captured in snapshots is to create subvolumes inside /home to exclude specific directories, i.e. $HOME/.cache, $HOME/.var, $HOME/.mozilla. Snapshots don’t include nested subvolumes.

Thanks, I hadn’t considered subvolumes to exclude specific directories. That’s definitely another option.

I’m a long time old school type, so don’t trust much of anything computer-wise[1]

So my four machines (2 desktops 2 laptops) have a dedicated / (root) with BTRFS … and a separate /home as XFS filesystem.

Every two days, I run rsync to backup the /home partition to two separate backup devices.

There’s gonna be that situation where a BTRFS snapshot won’t revert, just when you need it :+1:

I’m currently testing (SuSe) MicroOS Plasma (in a VM), and if it works out, I’ll convert two of the machines to μOS. (and still use separate /home).

I simply feel more confident having a separate backup on another device … each to their own, as they say :+1:
.
.
( [1] no fear of computers here, retired software and network engineer with 30+ years experience, plus author of a Linux book, plus some programming books, over 20 yrs ago).

I do use rsync as well, though not as often as I should. My hope is that using Btrfs will be an extra layer of protection against my habit of creating havoc :slight_smile:

I’m curious, what is the title of the Linux book?

@beepmode:

I suspect that, you’re thinking of enabling a form of file versions – like some Mini-Computer operating systems – for example, DEC VAX/VMS and RSX-11M(plus) …

AFAICS, UNIX® has always had the view that, if you want to keep track of your file changes then, use a revision control system.

  • Possibly the real reason why UNIX® never implemented user file versioning …

But, some UNIX® environments had, with system administrator effort, mirrored disk volumes which stored several versions of each file any user saved – and, because Samba was involved, the MS Windows users could also take advantage of this “nice-to-have” feature …


So, yes, Btrfs Snapshots could be used to take care of a “sort of” file versioning feature but, AFAIK it’s not possible to trigger a Btrfs Snapshot every time a user saves an edited file …


Personally, I’ve never liked file versioning when implemented as a filesystem feature – I’ve spent more than enough time using systems which had the feature and never really found it to be much use – my personal “edit / save” cycle sequence is usually much too frequent.

What I do make use of, is the editing history built into editors such as “vi” and, the editing history of Office applications …

For long-term revision control I currently use either Subversion or, for smaller projects such as choral sheet music engraving, simply archived file versions with time-stamps in the filenames …

A little bit off topic, but I don’t use Snapper at all for /home
Instead for incremental backups of /home exclusively I use Back In Time which is also available from openSUSE’s repositories.

No, I do you use git for version control (or at least I try to force myself to use git). I want to use Btrfs purely as an extra option to roll back changes, in addition to git and external backups.

I’ve seen filesystem versioning in Openindiana, which uses ZFS and has a “time slider” build into the file manager. That would be a nice feature but that’s not what I had in mind.