As some have noted throughout discussions here, there is no single solution to backing up your Silverblue system. I am trying to put together a short magazine article on using Borg Backup (which is available on F29 via fedora repos) as a layered package. What I am wanting to find out, and am asking for some suggestions and or links to documentation about the following
Real paths to directory locations, ie the difference between what the user and a layered application would “see” as the path on Silverblue.
Paths to, and are there metadata on the layered applications (ie version, etc…)
Paths to, and are there metadata on the flatpaks installed
Possibly, the flatpaks can be done by creating a script to make a human readable file which lists the apps installed in ~/.var/apps/ and just back that list up.
I know there is a web based GUI available for Borg Backup, and there is a script wrapper available and there is Vorta (3rd party, not open?).
It is a pretty interesting backup tool and I think it should be highlighted for the Silverblue community as a potential solution to backing up their system. I am well aware of Deja-Dup, and this is not a voting topic on which is better, I’ll leave each to determine that on their own. What I am asking is are you familiar with the directory structure of Silverblue and more pointedly the places information is stored that could be backed up to bring a system back to a known/desired state, layering, flatpaks, and all.
IMHO your thread here is a duplicate of the one there, as your Silverblue-specific questions are hardly specific to Borgbackup. And paths etc. are needed by all backup tools.
So about the borgbackup specific things:
Kinda 3rd party, but with involvement of original borgbackup authors. Also, it is FLOSS:
I started this thread for the info I want for the mag article. I am specifically focusing on borg since that was the intent of the article I am writing. Whether such a question is limited to the one thread or not is superfluous to the question itself. As for the details, if my thread is going to cull responses that are beneficial to answering both threads question(s) then what difference does it make other than “my thread is superior to your thread” type of attitude? I knew about your thread, and commented on it too, but your question is not my question.
I guess I’m more referring to the fact most of the deduping backup programs, and borg is no exception, don’t use symlinks normally, even hard links, they want the real path.
Okay, that is beyond what I was trying for, but I will certainly look at that. I’m trying to write a pretty light overview of one backup tool available for Silverblue. Since Deja-Dup is now a layered package, it can benefit from whatever I can gather together regarding howto locate and what, but I am only focused on borg backup for this article mainly since it is an alternative backup tool that doesn’t seem to get a load of exposure. Plus, as noted above, this is very similar to the thread @rugk links to. Which also mentions Borg as well as Deja-Dup.
Okay that is pretty much what I mean I think. I’ll browse through my directories.
However, as you can see, this doesn’t have version information.
ostree refs rpm-ostree/pkg (the repo defaults to /ostree/repo) will print all the layered packages and tehri versions, but it doesn’t distinguish between which versions are where, e.g.:
If you go the directory-walking route, you can check /var/lib/flatpak/app and /var/lib/flatpak/runtime for the different directories (or changed paths for your local install). For apps, you can then navigate to current/active to grab the deployment for the active commit, and then read the metadata file inside. For runtimes, you have go to whatever-architecture/whatever-version, e.g. x86_64/18.08 for the fd.o platform.
To me, the main thing that is different with Silverblue is that both podman and flatpak are going to be putting data in “unexpected” places within the home directory, so it may be hard to find everything to exclude. Some things that might be typically excluded:
So the info is there, just not maybe as apparent to extract. I understand where rpm-ostree would actually not have to care per se` about a commit since once it’s built, that’s pretty much that until the next update.
Yeah, I was looking at my home directory tree, even at 3 levels deep it goes on forever. Flatpaks sure do carry a lot of baggage.
I was doing a bit of playing with Borg 1.1.8 which is in the Fedora 29 repo. It does lend itself to scripting, plus there is the option of borgmatic from torsion.org that is a python script wrapper for automating the backup/prune/verify tasks. Thank you both for your feedback, I certainly have enough ideas to write a basic article, and I may bug you two some more as I work through things.
