You should pause the untrusted VMs, not the trusted ones.
If the hardware is flawed (vulnerable) and some VM can read the memory of another, pausing it just during backup is a security theater - the VM can read the whole memory, it can do it at non-backup time too. If such gymnastics are necessary, why would one need Qubes OS at all?
However, the attack would require the evil hacker to have code running on your processor. Only my code is ever allowed on my processor.
I donât quite understand what you mean by âmy codeâ but one of Spectreâs PoCs was through JS which the browser downloads and executes.
This is a good question. Maybe @adw could comment on that? I would say that at least the vulnerable VM will not have the password for all your backups. Not every file on the hard drive goes through RAM.
I donât understand your question. Itâs confirmed that automatic backup verification is not implemented in GUI. Itâs also clear that backups are important. If you need the high availability of your machine (and you use GUI), you will inevitably bump into such problem. Otherwise you could just give us an example when itâs not a problem like @adw did above.
I thought the problem you were referring to was having to stop all qubes when doing backups.
The only time I can remember something similar was recommended was to mitigate a transient exploit, while waiting for a patch to be deployed, but that has nothing to do with backups.
If an attacker can read the memory of dom0, I donât see how stopping qubes when doing backups is going to do anything meaningful to protect you. This is why I asked for an official source, to confirm stopping the qubes during backup is recommended.
Thanks for the explanation. So here is the most official link that I could find: Pause All VMs for Secure Operation
I would say that at least the vulnerable VM will not have the password for all your backups.
But the moment you resume it, it can read the whole RAM (that includes dom0 which you canât pause), i.e. also anything cached in it (like password), including dead processâs leftovers in case memory is not properly flushed.
I am not saying this is an easy attack - the attacker still needs to know which exact memory to read and considering the slowness of such attacks, that is a highly unfeasible scenario (for know vulnerabilities). The point is - security starts from hardware. If the hardware is flawed, âbeing carefulâ about how one works is extremely unlikely to help. Remember there are also Rowhammer etc. Too big field and quite off-topic.
Not every file on the hard drive goes through RAM.
Every data processed by the CPU goes through the CPU. Spectre, Meltdown and the like are CPU vulnerabilities.
this make me think it would be nice to have a dom0 notification when a qube start to have an abnormal resource usage like 100% CPU or network throughput.
I usually notice it when the computer fan start to be audible. In my case, itâs always due to a process not stopping correctly or a software issue, but I would like to know it earlier than by noticing through fan noise 10 hours later.
In addition, an unusual activity like this could indicate something wrong with a qube.
Good news, I just made my first backup of my Qubes system 
. Reading this thread made me realize how long Iâve been putting it off.
Congratulations! 
This thought is ârelatedâ but⊠just related: Isnât there a â3-2-1 ruleâ for backups? 3 copies of data on 2 media and 1 somewhere else? I also like the idea to implement to different technical solutions. So having snapshots and qube backups would be nice. And I like the idea to have an âassistantâ you can enable / is enabled by default telling you, that the last backup / external backup is x days, weeks, years old.
Iâm trying to provide an answer to the original question: why I didnât back up and why I donât right now.
TL;DR the different problems encountered were:
I believe that, starting with Qubes OS, doing a backup of the system was one of my first goals. But I donât know why I havenât tried to do it quickly. Maybe I got a bit lost on how to get back my previous systemâs data into different qubes and doing a backup of almost nothing wasnât appealing? Reading the documentation once again right now, it seems quite clear how to do the backup, but maybe itâs lacking tips on how to connect an encrypted USB hard drive to the âbackupâ qube? I remember having a hard time on this, altough with a good tutorial it should not be difficult.
Another problem: how to manage the passphrase? I didnât want to use the same passphrase between the backup file and the LUKS encryption. So I just stored it next to the backup⊠After some reflection, I came to this solution: the passphrase is stored in the vault qube, and I back up this qubeâs data in a second logical volume on the backup hard drive. Itâs not perfect, as the access to the hard drive is critical.
So, my first backups using Qubes Backup were a bit long, but acceptable. Maybe I had some doubts about the space needed, in order to keep some old backups. I seem to recall that the whole process was a bit painful: attaching the drive to a qube used to decrypt the LUKS container, then attaching the logical volume to the backup qube.
I think I still wasnât sure if I would be able to restore my Qubes OS installation with this file. It seemed like a big enigmatic file. But it was pure laziness, as the restoration process seems quite easy right now.
But after putting all my previous data in Qubes OS, the process became too long and buggy. So, after trying a few times to back up the whole thing (about 2To), and seeing a failure, I stopped doing backups. I wrote a script to run qvm-backup on each qube, in order to avoid the backup failure.
I also wrote a script to automate the disk decryption process. But, still, I had some qube, like one with 500Go of data, with only minor changes to track, and the Qubes Backup tool seemed unefficient. I need to add that I had not enough space to sleep without being next to my computer, and sometimes Iâve got some restrictions of power supply so, letting the computer backup while sleeping means bad sleep.
So I wrote another script to attach a logical volume of the backup drive to each qube and to do a backup of the data with borg.
In the same time, I learned how to use salt to at least install programs in templates. I had to write a script (yes, again!) to back up /srv/user_salt ⊠So, right now, Iâm only using Qubes Backup in order to back up dom0, debian-12-minimal template, vault qube, backup qube and a disks-manager qubes that serves to decrypt the backup drive.
Between the failure of the backup of all data and the writing of functional scripts, I had no recent backup. After this, I wasnât sure if this backup process was correct. Luckily, I had to change my machine, so I wrote the restore part of my backup script and I tried it on the new machine.
Right now, if Iâm not doing a backup of a qube, itâs because I need to do some manual steps to be able to use my custom backup script, like creating a LVM logical volume on the backup drive. But thatâs on me.
Although doing a backup of qubes is easy, itâs hard to correctly backup dom0 
Iâm clearly not satisfied with dom0 backup. Restoring it requires a lot of work, more work than a backup restore should involve.
If we could generate a list of changes done in /etc/ natively to include it into the backup, this would be valuable for people who do not use salt or automation to configure their system.
Right now, committing everything in /etc/ in a local git repository can help to generate a diff from the install state, itâs not perfect but at least itâs possible to see what was changed and to recover it easily.
If all qubes and qubes os related settings were moved outside /etc/, it would be easier to backup / restore the directory as this, because as the /etc/ directory contains hardware/user dependant configuration like fstab or passwd.shadow, restoring it could actually make the system unusable.
I wrote a script to back up ONE VM, based on the backup profile. If the script sees that itâs dom0 being backed up, it copies everything in /etc/qubes, /etc/qubes-rpc, /srv/user_salt and /srv/user_pillar to a directory in /home/<my-user-name>âŠTHEN it does the backup. (Obviously if you havenât created /srv/user_salt and /srv/user_pillar you need to do something else for salt-related stuffâŠif you have any of that at all! In my case, this isnât really necessary because I keep all salt files in multiple other places anyway.)
Certainly a restore would be a pain, because all of those files would have to go back where they came from. But itâs vastly better than having to regenerate them from scratch.
Regardless of all of this, I agree with your main point. This shouldnât be necessary. A lot of stuff on dom0 IS stuff the user ends up modifying yet isnât in /home/<my-user-name> so backup should be a bit smarter IMHO.
(And as long as weâre here Iâll just point out, once again, that listing all of the qubes one is NOT backing up, and giving people no way to shut that off, is annoying. I typically only back up a handful of VMs at a time because almost everything is autogeneratedâŠwhy am I being tweaked for that?)
My drive failed after @solene started this thread
i was so lazy and didnât want to do the backup even after reading over a hundred replies about backups
but then i did a back up anyway
then it failed
Ich stelle mir als die Frage, warum es keine Backup Möglichkeit gibt, so das ein Vollbackup Vollautomatisch ablÀuft.
Ich wĂŒrde zum Beispiel eine 400 GB groĂe VM fĂŒr ein Vollbackup bereitstellen. Somit könnte die Backup Software bei A anfangen bis circa 400 GB erreicht sind. Ist diese 400 GB voll, wird mir angezeigt, das ich dieses Paket jetzt auf einen externen USB-Stick ĂŒbertragen kann. Ist die 400 GB VM-Backup wieder leer, wird das Backup wieder automatisch dort weitergemacht, wo es vorher aufgehört hat. So ein Backup soll auch dann laufen, wenn ich gerade selbst am arbeiten bin. Man sollte diese Angaben selbst Ă€ndern können, vom Interval und Zeitabstand.
I would also appreciate the ability to resume backups if there is a failure due to storage size. I always back up to a USB device, but there have been a couple of times where I have forgotten to mount the device first, so Iâm putting the backup into the VM directly (which does not have enough space on it for even a single backup). Being able to point the backup tool to a partial backup file and say âresume where this file left offâ would be nice. I could see there being problems with this if some of the qubes being backed up have been restarted in the interem, because then the filesystem would be in a different state⊠so maybe store the checksum of the virtual disk and restart the process for qubes with a mismatch?
2 posts were split to a new topic: How to reply in another language?
I think there is a mixture of reasons, however i think the main reason overall is not awareness, its pain which comes from wisdom which usually comes from experience i.e. i ask people i know why they dont bother getting CCTV system for their home, their responses are mostly; why would i need that as i have never been robbed before?
I also ask people i know why they use Gmail as their main email address in the knowing that googly is reading their emails thus they are not private or why they use Playstore instead of Auora Store and fdroid and besides the obvious responses of I have nothing to hide when i dig deep i find a undertone of Laziness in need of ultimate convenience masked by ignorance.
My summary conclusion in general is that one usually needs to suffer enough pain before one usually makes an pro-active effort to try and prevent the pain re-occurring again in the future and that thereâs only a very small amount of people in this world that can either learn from others pain or pro-actively seek out preventative potential issues of their own volition in advance of any potential issues.
I am very lucky as i can usually learn from others mistakes as well as being privacy orientated and also have suffered enough pain in this life to of seeked out Awareness in the present moment.
I do backups of everything i can and as often as i can within practicable reason.
I think your post will and has brought some awareness to some to provoke them into doing backups already or at least consider doing so which is amazing as you are part of the solution. 
KISS. IMHO forget that people are lazy, ignorant and donât back-up. Thatâs life, the one thing nobody can influence is otherâs behaviour (regardless of how much people try).
Then for the rest of us, the 2 most important aspects are:
The ACTION therefore is make Qubes functionality that is easy to use and works reliably.
Great post btw.