Tks in advance.
rich.
It's my understanding that this is not only preferred, but also a really good idea, when moving to a new upgraded base system (3.2 ---> 4.0). But I'm no expert either.
The reasoning being that no data should be kept in dom0 anyway, so the only thing you loose is stuff like your XFCE4 configurations (or other dom0 system settings), and possibly screenshots you took (which currently are still saved to dom0). Stuff like that.
So by using paranoid mode, you only backup the AppVM's and Template VM's, without any base settings or dom0 files, (iirc). But even your Template VM's are redundant and can easily be re-installed on a new system. It might be a good idea to to not restore any templates either, because the code is in all liklihood different in Qubes 3.2. templates, compared to Qubes 4.0 VM-Templates. Moreover, if your dom0 was compromised, then your tempaltes were probably also compromised anyway.
So that's two reasons not to inklude dom0, templates or base settings, and only restore the AppVM's, due to not only security but also reliability. However, what I normally do, is just backup everything, pretty much dom0, any tempalteVM's, all AppVM's, everything. Then I put the backup at absolutely minimum 2 different places, and run an integrity check to ensure the backup is whole.
Once that is done, I only restore the AppVM's that I still need. If I ever unexpectedly need something else, then I still got the full backup laying around.
It's true that the backup-restore could be compromised as well, and reading the backup file from a compromised Qubes system could thereby exploit faults in the qvm-backup-restore. However, the odds for that is quite remote. For one, it probably would only happen to high profile targets, as it would require a targeted, and probably resourceful/costly attack. There is a big difference between automated, semi-automated, and targeting attacks. There is, imho, very low odds that any automated or semi-automated attacks even exist, and the code is so small and clean, that it's likely anyway.
At least in todays time, I wouldn't worry. If you just make a full backup, and ensure the integrity, then you should be okay. Even if Qubes 4 does not work for you, you can always fall back to Qubes 3.2. But keep in mind that Qubes 4 is still in testing phase, and some basic things are not fully working yet. To my understanding, it'll only come out of testing phase and become a final release, once it becomes certain that normal updates can fix any issues.
Also take note, that there currently is no graphic interface to backup and backup restore in Qubes 4.0. It'd be a good idea to practice in the 3.2. terminal before switching, so you know you can do it in Qubes 4.0.
If you want to exclude (-x) Templates, dom0, and some of the AppVM's, then you need to run several "-x AppVM-9 -x Template-5 -x AppVM-1" arguments, in the backup restore line. The order does not matter. You can run qvm-backup-restore first without the exlusions, to get a print of all the VM's, then type ctrl+c to break back to terminal, and write all the -x VM arguments you need onto the qvm-backup-restore command.
Also take note, you should avoid doing backup restore or backup create in dom0 in Qubes 4, as the code here apparently has changed since Qubes 3.2. I have no idea if its safe, but it's apparently slower to do it in dom0. You need a " -d AppVM (destination), for both backup restore, or backup create, followed by a pathline inside that AppVM.
Running qvm-backup -h and qvm-backup-restore -h will give you helpful information. Further using "man qvm-backup" and "man qvm-backup-restore" should give you the manuals.
Hopefully everything works out for you, just make sure to ensure redundancy, in case something goes wrong, and you can fall back to Qubes 3.2. Also to take note, Qubes 4 isn't ready for release or productivity yet.