Why did Qubes pick this backup strategy? I am aware that backing up several templates is not simple. But I think there’s a better way to accomplish this.
I’ve read a lot of articles recently regarding backing up VirtualBox VMs.
Would Qubes be able to use this method?
I have some bash scripts that checks all logfile timestamps and for any AppVM/template that has run since the last backup. I back it up into a directory structure organized by VM name. One VM per file. This is relatively fast for most vm’s but not my very largest which are backed up at the end of the day. It skips backing up anything that is running but also has a shutdown-vm option command switch.
For dom0 I back it up each time but include a tar file in /home/username that contains any custom changes such as /etc and custom scripts. The trick is to be sure the tarfile is kept current when making dom0 modifications. Upon restoring dom0 you just run the scripts.
This way I can kick off backups anytime and whatever is needed to be backed up just happens. Another mode will do the same but shuts down the machine when it is done. Any errors are trapped and the backup set is automatically verified so that broken backups are never retained. I have it locally mail me the log of the backup session so each time I boot I can see the results.
While this may seem like it’s waseful on drive space it is automatic so it simplifies my life. I always have 5 copies of each vm on hand and archive older ones. I just run a script and walk away at the end of the day.
You can read the historical discussion here:
https://groups.google.com/d/topic/qubes-devel/TQr_QcXIVww/discussion
Also, maybe this post
and especially @adw’s post after that,
could help someone to reconsider backup strategy and what is important/worth to backup at all when it’s about Qubes and security,
I appreciate and respect all your reply’s and all but the decision makers up top should decide whether they want Qubes and security to be only for the tech-capable people or for the average joe as well. It isn’t reasonable to say that we believe in promoting security and privacy for everybody AND that we expect them to deal with scripts and build their own backup systems and concepts (and much more) at the same time.
If the dev-team decides that they want this amazing OS to be accessible to regular users then things such as roll-back backup-restore should be provided as a simple solution that (preferably) doesn’t require more than a few clicks on the GUI.
I’m sure this requires time and effort and wish someone with deep pockets would decide to support/contribute so we can make Qubes more suitable for the masses.
You don’t need to use any scripts.
You can use the qubes backup tool, which has an easy-to-use GUI, for disaster recovery backups, and any other backup tool for incremental file level backups.
You’re right… and the very easy method to backup AppVM’s and Templates saved me countless hours during the years, but when it comes to dom0… well…
If something goes wrong there then it’s full on install from scratch and I hope you took notes of all the little changes you had to do to overcome hardware issues (at least in my case) when you first installed the OS some years ago (again, in my case).
Sure, but if you are making complex changes to dom0 you are not a beginner.
Just doing the absolute minimum like saving .bash_history should be enough to give you an idea of the modifications you have made, but anyone modifying dom0 should know how to back up their changes.
I don’t agree. When I first installed Qubes on this hardware I had several hardware related issues and although I am far from newby, I needed help from other users and posts in various forums and everything was working. We tried so many different things that documenting it all wasn’t feasible. Re-installing the whole OS might be easier in that regard since changes and updates were made to the kernel since then, but I wouldn’t wanna test it if it can be avoided.
I don’t think your experience is the norm, besides it’s made very clear that inexperienced users should avoid exotic hardware and stick to what is known to work, and given more than enough tools to do so though certified hardware, the community list and the HCL.
It’s not impossible to run Qubes without having to do anything but some very minor adjustments to dom0, if any at all.
Most of the new users I work with make no changes in dom0.
But they have generally worked with machines that are guaranteed to work
with Qubes with minimal effort.
Where users do do stuff in dom0, I always tell them to maintain a log
in /home/user and to copy any edited files to a config folder there.
@renehoj @unman It seems to me that I try to represent a broader group of users while you focus on a much narrow group - one that (for instance) can even acquire the hardware that perfectly match the HCL. Where I live, the available hardware isn’t the same as in other places, and older parts are nearly impossible to get. I had no choice but purchase a Gen10 CPU, a new ASUS board that wasn’t mentioned in the HCL, with built-in intel graphics that made installing the OS crash and so I had to purchase a NVIDIA graphics card that up until today doesn’t perform flawlessly. everything that is related to hardware is in the realm of dom0 and anything I would like to try and fix there is under the threat that if anything goes wrong I might find myself reinstalling the whole thing again. All I’m asking, for myself and any user in the world who wants to join the Qubes family but can’t find any of the few hardware combinations listed in the HCL, is to have an easy way to roll back dom0 in case something goes wrong there. preferably without having to do a full bare-metal backup.
The real question here isn’t my specific case or problem, but rather “how easy do we want to make Qubes-OS for newcomers?”
The path you suggest sounds like it has many restrictions (knowledge, hardware, learning curve) while the path I believe in is a more “whatever you have or can afford - bring it on and we’ll help you out as much as we can, because we think security and privacy is for everybody”. 
The problem is that so many user wants Windows based on Qubes.
I have no idea how you draw this conclusion from what I said, and I find
it pretty offensive, “slightly smiling face” notwithstanding.
Even if you are lucky enough to be able to afford " a Gen10 CPU, and a
new ASUS board" I would still recommend that you maintain a log and
copy edited/created files to a config folder under /home/user in dom0.
I would never recommend that someone go about “trying so many
things” in dom0 without keeping such a record, and keeping backups of
what has been changed in dom0.
That approach does no one any favors, newcomers or not.
There’s an open issue for this:
on the contrary my friend, I explained that I couldn’t get my hands on anything on the HCL and got stuck with new hardware that wasn’t fully supported in the kernel.
I apologize, as I didn’t mean to offend, and there were other comments in the thread so I’m not even sure I replied to you directly.
as for “trying things on dom0” - let’s say you have a problem, and so you check in the forum and see a solution “run this command in dom0…”. now the problem still isn’t solved, so you go and try something else, and so on. not all the commands had the desired effect, if any at all, and since there’s no easy way to roll-back those changes, it’s not trivial to do a full backup and restore after each try.
I just realized that this thread came to my attention just because enmus quoted my post from another thread. I don’t think Qubes backup is bad at all, I just miss the rollback option for dom0.
apparently there is, and there’s a long discussion in there… thank you, i’ll dive into that tonight. looks promising 
Thanks @adw - looks like this wraps it up
I didn’t know Tasket opened it back in 2019, and I see that it got pushed to ver 4.2, but the issue has been discussed and decided, so now we wait.