Currently, the backup utility allows creating backups of VMs and of the private part of dom0, but not of the complete system. A complete backup can be done using dd from another system, but, from a security and comfort point of view, this is not optimal at all.
What is needed is something like the functions backup /physical for blockwise backup of a complete system, and backup /image for logical backup used in OpenVMS, which have been available there for over 40 years. These functions, however, show that such a thing is not trivial at all, but a major undertaking. It would be really good if someone could bring up the time, resources - and courage! - to implement such a thing.
Learning Salt (or Ansible) is a good interim option until work is finished on a new/improved backup system. Salt can configure dom0 and qubes (like templates) and you can backup the qubes with data. It’s a time investment, but it’s stable and works well. It also has the benefit of smoother transitions when installing major (and minor) updates to Qubes.
For this I recommend clonezilla as live usb. It can backup a full disk, encrypt the backup, and even decrypt luks volume to only save real data. Then it can restore everything, including the bootloader and the luks volume, it’s really good.
I second that @solene: Clonezilla has always been my bottom line defence for when things go pear-shaped. It’s gotten me out of trouble a number of times. As far as saltstack goes, it might be a “stable” system but it breaks regularly on Qubes, usually with changes to the required subsystems like Python, template versions etc. I have found it pretty frustrating and look forward to a stable ansible version for Qubes.
Interesting. The only time I’ve ever had Salt go pear-shaped on me was the issue with Debian and updates, but otherwise once I create a working config I’ve never had it fail to do the same thing later.
Unless I have not found it, a simple way to access the SeaBIOS for a HVM. Currently the splash screen default is like 2.5 seconds. No time to activate window and access. Virtualbox/VMware Wkstn/HyperV have either menu or checkbox to force the BIOS to open on restart/boot.
I was trying to install the blackarch installation. It seems to recognize if your bios is set for EFI boot or not. If it isnt then it obscure partition setup options to only use dos options. I would think in the SeaBIOS this would be configurable. I have seen other installers do this also.
Another thing I would find quite useful for development/cybersec work would be a more “traditional” way of taking VM snapshots.
I am talking about ones that would not get automatically overwritten. I don’t think changing the whole snapshot system would be a good direction, so maybe just a way to “pin” a specified volume snapshot? With GUI integration in the future?
Something I do when experimenting is qvm-clone whatever VM I’m working on, with some date/version naming convention. Works ok though qvm-ls can get messy.
It would be nice not to have name collision with block devices. When I have /dev/sda disk on my computer (dom0) and I attach USB stick to sys-usb (/dev/sda), it has caused problems.
Ability to have templates and devices switched automatically on next boot. It’s sometimes difficult to switch templates to sys-net or sys-usb which ideally needs to be always running and you can’t change template on running VM. Maybe this is just a skill issue, I don’t know. Also permanently attached block devices are too painful to use when there are some problems and this kind of mechanism would make dealing with those easier. I don’t remember too clearly what was the exect problem, I already gave up trying to use them and just manually set block devices each boot.
It would be nice if there would be smarter filesystem layering that would allow installing dnf -packages just to AppVMs withouth entire custom TemplateVM or other complicated setups. I get that there are tradeoffs and this current way is simple to understand and works well enough, besides I don’t really even know how it should work but I’m thinking something like docker has.
My stupid solution for this is to install the package from rc.local on every boot. It’s possible to cache the files by making the package manager file cache persistent in the appvm.
I have posted some replies in this thread but never said what I would personally like to see improved in Qubes OS. And this is the only major one. I would like to see this issue is solved:
Let me explain. Without properly written abstract README files, potential contributors have to study individual repos and their components to understand their relevance and how they work. This might be a barrier to some first time contributors. Regretfully after understanding the workflow, many of the contributors do not go back to improve the README files (yes, I have to blame myself for this).
If any of the past contributors is reading this, we have technical debt to new generation of contributors. Kindly consider improving the README files if you have time and patience.
