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.