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 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
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)
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.
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
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!
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.
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! 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.
Please tell me you are taking regular snapshots of your zfs datasets.
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
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!
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.