Hi! After many weekends working on this, I’ve finally published the first of my promised video tutorials:
(Watch without google tracking on invidious)
17 Likes
In regard to backing up dom0, I copy the rpc and policy areas into a subdirectory of my home directory before doing a backup. That way the actual files are copied. Of course that puts the burden on me to copy them back to those areas after a restore…but that’s easier than regenerating them from scratch (by about four orders of magnitiude). So I am not sure if that counts as having to “reconfigure” dom0 after a restore.
True. I do the same. But I wanted this guide to be as simple as possible and jumping into a terminal to do that would require so much more explanation that I decided not to mention it.
2 Likes
Symlinks modified files to a directory in /home/ could do the trick
2 Likes
Nice Orwell touch, not missed in any frame.
1 Like
How about a simple procedure that would work flawlessly, although would take about an hour to complete. Using Macrium Reflect in recovery environment (RAM) you could do a forensic level backup of the Qubes NVME entirely - bit by bit. The entire drive including the LUKS super block would be backed up and verified. Then to restore obviously you would simply write back the saved forensic entire drive copy. No file to manipulate or move back and forth, just a 100% forensic snapshot so to speak. That is how I backup my Linux systems hiding under a LUKS “blanket” and those custom installs would be a total pain to rebuild, no thanks.
Just an idea here. I am studying Qubes before jumping in the pool but this approach certainly must work I would think.
ps - my backup times were averaged using a 500 GB drive and using a 20-40 gig connected drive with appropriate quality ports up to thunderbolt or at least 10 Gig. On my older Lenovo i5 the backup takes almost 3 hrs but it has been acid tested at least 10 times over the years — flawless restores.
If you have a way of backing up that is faster and works for you, then it’s perfect. I have heard of similar setups in the forum, for example this discussion.
With that said, the Qubes backups already had quite a bit of thinking behind them:
- restoring from a compromised backup won’t compromise dom0 (whereas a forensic copy of the image won’t)
- you can have granuar backups (i.e. only certain qubes)
I also thing that improving the backups application is one of things the Qubes developers should improve in the future to make it a one-step process with snapshots (apple time-machine-like). The current backup scripts are just too slow.
Lastly, for the sake of a video tutorial, the target audience were newcomers into Qubes, especially people who don’t have patience to go though documentation and forum posts. So anything other than a click, click, click wouldn’t work.
And best of luck on your Qubes journey (should you choose to embark on it) 
That feature would be really sweet for me. MY method is thorough and works perfectly BUT its an all or nothing thing. e.g. – backing up 500 Gig just to secure one or two VM’s is painful, LOL!!
I will follow up with you here IF I ever get in the game! Your efforts are to be appreciated.
edit: I went to the backup thread you linked above. I really wanted to jump in on it but its from 2020 so I decided not to join in. Backing up data is a specialty of mine. I do really like taking snapshots with my machines DOWN. Just as with a physical camera you get the best picture when the “subject” is standing still. And of course in the 3+ years since that earlier thread stopped we now have thunderbolt and others that allow data to be offloaded at “head swimming” speeds. Massive hardware improvements are exactly great for where Qubes is headed.
1 Like
Technically the Qubes OS backups make a snapshot of the non derived disks, while running qubes are using a temporary disk that get merge during some step (I can’t remember if it’s on shutdown or startup). You never backup a live system.
I am handicapped here in that I don’t have a Qubes OS to examine what your are saying. I like your wording and if it happens as you state that would be nice!
Just for comparison; have you ever taken a linux live disk and unlocked the LUKS super block on a DOWN Quebes system NVME/SSD, etc…? I am asking because many times a non-running system with the LUKS header unlocked will allow a very thorough look around. There should be no danger (if you know what you are doing) and a complete examination of the specific contents might be very helpful. I personally like looking under the hood for the structure and how it fits.
ps - I hope I am not exasperating readers since I am asking questions without even having a working system yet.
Yes, but you will have a LVM pool to backup because all the qubes/VMs data are stored using LVM volumes (by default, but it can be possible to use xfs or btrfs instead of LVM), there isn’t much to explore, and it’s a bit of a mess as there are many volumes out there.
The one thing I don’t like about the backup utility is that it insists on showing you a list of every qube you aren’t backing up. None of the command line switches for quiet mode, etc,. affect this. When I’m just trying to back up three or four qubes, the useless list of qubes I didn’t ask to back up scrolls what I want to see right off the top of the terminal.
I agree, by the way, with ADW’s rationale for not including my tip about dom0 backups in the video; I’m just hoping someone finds the tip useful.
Thanks for taking the time to respond. I didn’t consider that each Qube/VM would have its own LVM. Makes sense. If you can easily identify which mini-LVM goes with a specific Qube you could then copy that off. Then open it on its own at the new saved location and look under the hood.
Assuming the LVM identities could be certain maybe copying them to a backup drive could also serve as a specific Qube backup? If a restore would be needed then a specific backup is available. Just shooting from the hip here, LOL!
don’t forget that the Qubes OS backup tool also includes metadata such as the qube name, CPU and memory assigned, firewall rules, PCI passthrough, services, NetVM etc…