/etc is a weird amalgamation of system- and human-created and edited files.
When reinstalling a system, for instance, one should not copy all files from a backup into /etc, as drive UUIDs, etc. might have changed.
It also isn’t possible to, say, back up files that have changed since the system install datetime (via /etc/machine-id, perhaps), as most files in /etc are touched by system updates.
I use chezmoi to back up my ~/.config, etc. to a github repo, but it doesn’t work with folders outside $HOME.
One approach is to copy /etc into a folder in my $HOME, then pick and choose what to back up from there. But this seems clunky, and perhaps failure-prone.
Also, are there other folders similar to /etc that require the same attention?
Suggestions?
(I do keep regular bare metal backups of /mnt/btrfs-root/root, /mnt/btrfs-root/var, and /mnt/btrfs-root/home, along with Vorta backups of everything else.)
Can’t you just use the native snapshot feature of the btrfs filesystem?
For example my Documents, Pictures folders are in a btrfs subvolume that I created /mnt/userdata . Then symlinked back to $HOME.
I moved my Desktop folder into Documents.
This way for my personal files I can simply backup userdataor use whatever sync tool to sync to a cloud or private cloud.
Or even use a tool like btrbk to daily snapshot and sync this subvolume to a different drive or even to another pc/laptop (btrbk supports ssh).
You could probably create a subvolume /etc1 do a mv /etc/ /etc1/, then delete the first folder and rename the other to /etc.
Now you can easily snapshot, compress sync or do whatever you want with it via btrfs.
I believe (could be wrong) OpenSuse Tumbleweed or Manjaro actually uses separate btrfs subvolumes for these typical Linux folders.
I’m surprised Fedora Silverblue doesn’t leverage the btrfs snapshotting features more.
Thanks. Yeah, I think the above, from my original post, is where a lot of the difficulty comes in.
I have a script that snapshots root, home, and var, then uses rsync to do an incremental backup to an external drive.
I also use vorta to backup up my home and data to my iMac that backs up too Backblaze.
So I’m covered on backups.
But, etc is different due to the mix of system and user configs.
Regarding “etckeeper”, is it possible to layer it without the dnf dependency, e.g. “rpm-ostree install etckeeper --excludepkgs=dnf”? It might solve the problem of dnf messing with the rpm-ostree upgrades. Just a thought, I don’t know if it works.
Or just to use plain git sync with git-crypt (homebrew-installed or layered in) to protect sensitive information?
Another option is to make a systemd service and timer that will make regular backups of /etc directory and place the tar.gz files in user’s home directory, with optional pruning (removing the old ones after a while). That way, the etc folder tgz “snapshot” can be saved using Pika backup or some other home folder backup app.
BTW, thanks to all the developers for the finest set of linux distributions that I encountered since 1994.
I had looked into this as well, wanting to use git for tracking changes in /etc. Unfortunately, from what I’ve read, etckeeper is just not going to work as it uses hooks into dnf.
I like your idea of basically engineering something with systemd and git. Maybe that would work.
The concepts around the ideas presented here are definitely worth considering.
Here is where I landed.
I realized that creating a git repo out of the entire /etc dir was too heavy handed. Very few files are customized over time.
It would be better to track changed files in /etc by copying them (don’t forget the details: perms, SELinux attrs, special file types, etc.) to a dir in $HOME that is practical to be a git repo.
This allows them to be included in the backup of $HOME to NAS, compared to /usr/etc, use git diff to analyze changes over time, etc. And minimize manual post-install steps.
I am definitely not proposing my solution (don’t do what I do). Rather, I am simply offering some food for thought …
Sounds interesting. Yes: perms, user/group owners, perhaps file types must be recorded and backed up. Is it really required for the SELinux attrs? Because, if I copy something back to /etc/ wouldn’t it be labeled according to the policy for /etc?
But there have been more than one occasion where someone has pointed out that a problem upstream (from my laptop) has created a situation where a restorecon or .autorelabel was needed.
Before that realization was made, some troubleshooting needs to be done. Without some record of it - what were the attrs set to before? And if the dirs / files in question were added from a layered package - (such that they do not exist in /usr/etc from the image) - now what?
It is just an important detail to consider. I prefer to have a record - just in case.
Hope that makes sense.
EDIT: guess I should have mentioned that this command (or equiv) preserves the SELinux attrs (just one of many ways to go about it):
