Btrfs+luks+snapper

hi
i was reading the BTRFSonLUKS howtos on the wiki, which looks very doable, but it talks about timeshift. timeshift as far as i can tell is only available from the aur, and i prefer not to use aur, plus im used to snapper from opensuse tumbleweed and snapper is in the regular arch repos as well from what i can see. is there a guide how to do it with snapper instead?

thanks :slight_smile:

Welcome to the forum!

I don’t think we have a prebuilt guide but you should be able to replace the timeshift parts of the tutorial with snapper if you already know how to use and configure it.

I am using snapper in my endeavouros install on my laptop. I didn’t hit any special snags when installing it. It more or less worked as expected.

thanks for the reply
i know how to use snapper but not how to set it up (subvolumes etc) as that is done automatically on opensuse, but i suppose i might be able to find a howto somewhere, and just follow the guide on the wiki and stop where the timeshift stuff starts and jump over to anything i can find about setting up snapper

Maybe if you watch the this tutorial video you can see those parts and do it?

Edit: How to install Arch Linux with BTRFS & Snapper - YouTube

This is purely a matter of personal preference, you don’t need anything special for snapper. The tutorial already goes over creating subvolumes.

thank you, ill watch that video tomorrow, its getting a bit late for a 45 min video tonight.
that vid has a link to a page on the arch wiki that looks useful as well. thing is i dont know what subvolumes i need, iirc opensuse created a whole bunch. what is neccesary really? i mainly want to take snapshots when installing or updating via pacman, + maybe manually. its a fairly regular system ive got with nothing special.
i mostly want to be able to roll back if and update completely breaks the system beyond repair which happened a few times on manjaro (i dont know if arch/eos is as prone to breaking as manjaro is though)

You need one for /, other than that it is all personal preference.

That being said, the installer creates 4 subvolumes by default.

  • /
  • /home
  • /var/cache
  • /var/log

That is a pretty reasonable default unless you have special needs.

If you want to setup snapper for those subvolumes, you need to do:

sudo snapper create-config /
sudo snapper -c home create-config /home

Then you can test snapper to make sure it is working with:

sudo snapper create
sudo snapper -c home create

If it worked, you should see a snapshot when you use:

sudo snapper list
sudo snapper -c home list
2 Likes

thanks again all.
i think ive got enough to give this a proper go this weekend

1 Like

What does the snapper create with the above commands. Does it make snapshot of just home? Or does it also take a snapshot of / and anything else?

sudo snapper create creates a snapshot of /
sudo snapper -c home create creates a snapshot of /home

You can configure it to take snapshots of whatever subvolumes you want but in the above case, I am not sure there is value in snapshots of /var/cache and var/log. But if you wanted to, you could take snapshots of them too.

1 Like

I might try reinstalling EOS and set this up just for learning purposes as i already have the btrfs wiki setup on one computer.

2 Likes

@dalto
But after i have to do more setup? Correct?

Edit: So i need to RTFM

https://wiki.archlinux.org/title/snapper

I suppose it depends what your goals are.

If you just want regular snapshots you can enable snapper-timeline.timer.

If you wanted automatic pre-transaction snapshots you can setup snap-pac.

The list goes on from there.

I find that I did not use TimeShift or Snapper, even with the multiple distros I run (mostly Arch based). The most likely breakage scenario that I can conceive involves an update going bad, and snaps are not needed to recover from that! Arch has a comprehensive and proven system of maintaining archives that allow ‘returning’ to a specific date as far as updates (and general package state) are concerned. Doing this is no harder than activating a snapshot, and eliminates the need for hooks to automate them and maintenance of only the correct(?) number of relevant ones…

Just my opinion, of course :grin:

There are a couple of Wiki entries (on our wiki system, under pacman) on how to return to a specific date easily as well the Archwiki (of course). I even set up a simple script to make it as simple as clicking on a calendar to pick the date!

1 Like

A few things:

  • Rolling back updates isn’t the only value of snapshots. On real machines, you really should consider enabling snapshots. They can be super useful in a variety of circumstances and they cost very little to enable.
  • You don’t need to use pacman hooks you can also take snapshots on a periodic basis. Both snapper and timeshift will automatically clean the old snapshots up for you.
  • There are tons of problems you can’t fix with pacman that you can repair with a btrfs snapshot.
  • The archive-based rollback strategy is only effective if you have a network available. On top of that, it can be a pain to use if you have a lot of AUR packages with specific dependencies.
1 Like

True enough, I suppose. The additional ‘added value’ would be very low in my situation, though, as I have other similar setups on the same system. Retrieving configs and settings and things like fonts and themes and other customizations is a low-intensity procedure for me. I tried setting up Timeshift before, and found it was not useful for me, especially with the amount of setup, maintenance and space it seemed to require. It would have been easier if I had been on btrfs of course.

I didn’t know of snapper - it may well be a better fit for me. The automation of Timeshift in rsync mode seemed unsuited to my purposes…at least without hooks it would have been!

Not too sure what those problems may be - but I am not a real fan of btrfs to begin with (not from knowledge, probably just bias - but I tend to run f2fs for system and zfs for data mostly).

True enough - need a network. Of course, having network access is why I have computers so I would be fixing THAT before trying a recovery! (YMMV). The AUR thing could be a PITA, but again I have access to the yay cache on my other systems, even without network - which should handle most if not all restorations.

I don’t suggest that all should eschew the use of snaps - just wanted to point out that the most frequent cause of needing them can OFTEN be fixed in another manner… especially if your setup is like mine! :grin: Don’t you all love choice?

I mean, we are specifically talking about btrfs snapshots here. Timeshift’s rsync snapshots are something else altogether. btrfs snapshots take very little space unless you keep them for long periods of time and/or have massive change rate on your data.

I don’t use hooks with snapper, I just let it take periodic snapshots and prune them for me.

Well…I guess the conversation isn’t relevant to you then. :rofl:

Please tell me you are taking regular snapshots of your zfs datasets. :pleading_face:

If not, you should think about it, zfs snapshots are even less expensive than btrfs snapshots. There are also much better tools for managing them. For example, I use znapzend. I like it because it stores the config in the zfs dataset which makes it much better for my multi-booting scenario. No matter which OS I am in, my snapshot automation keeps working as long as znapzend is installed and running.

Of course, there are plenty of other tools which work great as well.

Examples of things I have seen people do that could trivially be fixed by a snapshot:

  • Recursively changing the permissions on / or some huge subset of their data.
  • Accidentally deleting or modifying a file
  • Deleting /var
  • Virtually any action that would be annoying or disastrous can be easily recovered from if you take snapshots.

Again, if you are running brtrs or zfs, you should be taking snapshots. The cost to do so is impossibly low. Even if you only need it once or as an occasional convenience it is worth it.

As a side note, I have never once needed to rollback due to failure after an update. That is across a span of many concurrent installs over a period of more than 25 years.

Thanks for the clarifications! I have managed not to recursively mess up permissions for many years now - but then again I learned a while ago to read what my command line actually says more than once before ENTER gets hit. The other nightmares you mention haven’t even crossed my mind (yet). I think this thread will enlighten more than I expected - including me.

My main intent was to point out a (probably inferior) alternative - but I get some ideas for future improvements. ZFS snapshots are much more to my taste, BTW - though I haven’t found a comfortable tool for it as yet (thanks for the app namedrop!)

I can’t imagine never needing a rollback for that long a period - as my experience suggests that (rare as they are) they are nearly the only thing that ever causes trouble (example - when XFCE 4.14 arrived with serious graphic consequences, and some fun with kernels). You must be uncommonly fortunate - or have a better update strategy than I do! :grin:

If you are looking for options I would speculate than znapzend and sanoid are the most widely used. sanoid is easier to setup but znapzend works better in a multi-boot scenario for the reasons mentioned above.

It is probably more about how I deal with problems than anything else. When I have issues with kernels, I would just switch to a different kernel. If that didn’t work, I would downgrade my kernel and any related packages. That wouldn’t cause me to trigger a rollback of all my updates.

I don’t run xfce, but if I did, the same thing would apply. I would downgrade the xfce-related packages. If I couldn’t do that because of shifting library versions I would either live with it, or rebuild the working version of the packages against current libraries. That being said, I have never found a situation requiring me to build a DE myself. Though if you ever need to, it isn’t as hard as it may sound on Arch.

EDIT: To be clear, I am not advocating partially downgrading your system. That is definitely a risky proposition if you aren’t familiar with how all the packages are interdependent and what the implications of downgrading certain packages are.

Actually - it was the amount of work involved in downgrading certain things (the 4.14 XFCE for example) that motivated me to investigate more thoroughly how the Archive system worked, For the downgrade, I needed to find multiple packages that needed downgrading, select what version they needed to be downgraded to, and check that they got properly ‘ignored’. The same thing (though less involved) is true of kernel troubles - unless I can live with an LTS or something. The comparison with the simplicity of just ‘backing off’ the one set of updates without even having to know what they all were by just giving a date and a command - all seemed good to me.

The other advantage for the less knowledgeable is that less needs to be researched as to what dependencies might be involved - as I certainly would not know off the top of my head what they might be! Yes, there’s a pacman command for that - but the ‘comfort level’ is considerably lower.

I haven’t built any DEs either - and all I needed was a day or 2 until workarounds and such appeared - and the final ‘fix’ was actually derived from interaction on the Arch forums (to my surprise).

I guess it mostly comes down to viewpoint - and experience level. The Archive setup does work amazingly easily, and from a certain viewpoint it isn’t a bigger intervention than a downgrade - while also making sure that all inter-related pieces are ‘downgraded’ together.