crestic VS btrbk-pac

I've had a good experience with [crestic](https://github.com/nils-werner/crestic), even though it seems a lot smaller and simpler than autorestic.

BTW you can use secret-tool to easily retrieve passwords in scripts, without having store the plain text password in a script. You could look at crestic as a configuration helper for restic. Theres a couple of others as well.

Also, can I interest you in using crestic too? 😉

I also use btrfs, but I use btrbk to manage the snapshots. I use some scripts I made called btrbk-pac so that every time I use pacman, I get snapshots before and after the transaction, logging the affected packages in a file (tbh I'm not super proud of the solution, and started making a cleaner Rust version some months ago which uses yaml for configs, but never got around to finishing it). That's for the stuff under /, while I just have a cronjob take care of hourly snapshots for /home.

I just realized that suddenly, gtk apps are following that rule. I looked back through my previous pacman commands (I created some scripts that log the affected packages when I use btrbk to snapshot through pacman hooks) and found that I upgraded the following on the night of the 30th: kdecoration breeze breeze-gtk kde-gtk-config along with a bunch of other KDE programs, so I think that update might have fixed it.

Btrbk and the pacman scripts I wrote for it automate the creation and maintenance of snapshots for me, which is most of the the interaction you'll need with snapshots. And then when it comes to actually accessing them, just copying individual files/directories is what's done the vast majority of the time.

After adding all the stuff for SSH and feeling kind of gross about it (this is the original and this is after stapling together SSH stuff), I've kind of been thinking that if I add too much more complexity to this project that I might be better off just transferring it all over to Python or something else. Shell scripting isn't much fun when going much further than 100 lines, lol.