Qubes Backup utility has not worked since I upgraded to 4.1 and I’m starting to worry. I’ve never gone this long without backing up, but didn’t think to test backups until I’d already been using 4.1 for a bit.
Is there a way to backup qubes without the built in backup utility, that is reasonable to use to restore a system, if I need to revert to 4.0.4?
full disk backup?
Well, I could use dd to copy the whole disk, but then is there a reasonable process to restore the qubes in a new install of 4.0.4? Is that what you’re asking re: full disk backup?
I want all my qubes backedup to transfer to a new Qubes install.
so you want to just backup your qubes not anything else (dom0, disk password)?
Yeah, just the qubes would be great. I can copy my dom0 settings.
so the builtin backup is only way
i confused what you mean
oh, with Dom0 in my experience i’ve had to backup any changes I’ve made to Dom0 separately as they don’t get saved by the Backup Utility. [edit: only the home directory of dom0 is backed up, so changes in /etc/ or elsewhere must be backed up manually]
that’s what i was afraid of, thanks
If using the default lvm thin pool configuration, try: GitHub - tasket/wyng-backup: Fast Time Machine-like backups for logical volumes
B
I have a luks encrypted RAID setup, but otherwise i just let the installer do its thing. So not sure if that is the default lvm thin pool configuration?
Thanks for the reminder I think I read about Wyng before. I will read thru this.
That guide shows how to revert to a previous version. But can you copy those private volumes to another drive, reinstall Qubes, then copy them back in and have your qubes back?
I never tried that, but I don’t see why not.
Yes, you can.
An alternative approach is to focus on backing up the data.
If you salt the creation and configuration of templates and qubes, then
you can recreate the system relatively easily, and restore the data.
(You can also do this with bash scripts in dom0, but such scripts readily get
out of hand.)
I don’t know what that means, but I’ll try to look it up.
Sorry, I should have been more clear.
You can create your Qubes system post install in a number of ways- among
them:
Just create new templates, install software as you want, perhaps
configure individual qubes. Unless you write down what you’ve done, it’s
quite difficult to recreate the system without a working full backup.
Use scripts in dom0 to create templates, install software, etc.
I used to do this - the scripts can get quite unwieldy, but it is
workable. (There is a lot of qvm-run use.)
Use salt to do the work. Salt is a management tool used in Qubes as
part of the post install configuration. You use salt every time you use
the Update tool.
There’s official documentation and
I have a simple introduction with many examples here
Thanks for mentioning this alternative.
Do you know, if there are any hard advantages of Salt, which cannot easily be replicated with shell scripts?
I implemented reproducible template/appvm/whatever installation recipes with simple shell script wrapper functions over qvm-run in dom0
- e.g. to facilitate executing inline code via here-documents.
This works quite well with now over 20 templates, their appvms and disposable templates.
There is nothing in Salt which cannot be done with shell scripts.
What there is, is a ready made module and templating system, which
simplifies many tasks.
As an example, Salt has a pkg state module, which covers package
management for Fedora, Debian, *BSD, Arch, Suse, and (I am told)
Windows.
So one call to pkg.installed can be used to install packages across
many templates, regardless of OS and distro.
By contrast, the shell script has to call the specific package manager
for each template.
Of course, package names can differ between distros, and Salt allows you
to take account of this in the list of packages to be installed, by
reference to the target.
It’s not that you cant do this in a shell script - you would probably have
to build in a call to qvm-prefs or qvm-ls as part of an if/case to
do it.
Then there are dependencies between states, and ease of updating.
For example, I was able to modify my salt configuration to use Debian-11 and
Fedora-34 by editing 2 lines in 1 file. Everything else built as
expected.
Salt is not perfect. It’s much easier that most people think, and
once you have a working system, it becomes second nature.
No need to over-complicate this. Your personal data is the most important thing to back up. Qubes VM configs can be recreated. Templates can be re-downloaded and re-customized. Your documents, photos, etc. cannot. Luckily, you can do pretty much anything that you’d do in a normal OS inside of Qubes. This means that you can use conventional backup methods in Qubes too. As a simple example, you could attach an external storage drive, then simply copy your files from each qube onto it. (Tip: Use LUKS encryption on the drive and do the encryption, file copying, and decryption in a more trusted qube. This prevents a potentially-compromised USB qube from snooping on your data and protects your data at rest on the external drive.)
Sure, and I’ve done that before. However, I just spent a few days backing up and reinstalling everything from scratch last month when I migrated to 4.1. I have servers and things configured that are not just a matter of copying files over. Finding the time to do that again is not easy.
4.1 seemed to be working almost flawlessly until I tried to use Qubes Backup. And then spent time trying to play with that. By then I’d already accumulated a lot of new data. I suppose a compromise would be to rely on my month old backups and just copy data to another drive and restore to those in a fresh 4.0.4 install.
Another simple solution is simply to clone your entire drive. This may not allow you to downgrade or restore back into 4.0, but at least you’ll have a backup of all of your data and configs in their current working state in case you ever need a model from which to reconstruct configs.