Clean Reinstall + Install Packages and Previous Configs as a Way of Backup/Restore Process

[enmus]

Thanks all for your responses.

Everything would be easier if I made notes about changes in a timely manner, now I don’t have an idea in what all the ways I tweaked my Qubes… If I’d knew, I’d backup only data, not VMs themselves.

I’d start from here

@Sven

Hence I think the motivation for your question was maybe a misunderstanding of what restore would do?

I wouldn’t say so, but also wouldn’t exclude you were right.

I guess @fsflover recognized where I was heading to regarding domUs (although he liked adw’s post, so I’m not sure). I was planning to discuss that later, after defining suitable frame for “restoring” dom0 after clean install first. Sorry for I wasn’t clear enough (I was thought not to use “I was misunderstood” and that “others didn’t understand” was even worse).
Anyway, to clarify

@adw

we do not assume that every qube is compromised by default

I didn’t say anywhere every. I just didn’t elaborate it in details, trying to focus on dom0 first, although I don’t see anything wrong even someone who follows Qubes’ concept, to consider all qubes as compromised. Less dangerous than vice versa.

@adw

if it were true, it would make it impossible to meaningfully restore data from a backup.

Again, I didn’t speak about data, but about backup - of a certain qube in whole. Inside Qubes, I keep data only in vault, so I consider it meaningful to restore the data from a vault backup, but not the vault itself.
Why? Because it’s bloated with unnecessary packages, as I said it was the other main reason (when qubes aren’t compromised). Am I wrong or missing something with such constellation?

@adw

It seems to me that such an approach is unlikely to provide any meaningful security benefits.

Dom0 is bloated at the moment (“I’d revise which packages once manually installed I want again over clean install, … and which don’t.**”). Doesn’t such an approach mean smaller attack surface? So I thought I clearly saw security benefit from this?

And this is perfect to get back to my question about dom0.

@adw

@enmus

So, for the start, is there a way to compare my current dom0 state with the one provided by .iso (I know 'default" state is relative term, but I have to start somewhere) by getting human readable text?

I’m not aware of any such thing, nor can I even imagine how it might be accomplished in a practical way.

I was hoping to hear something like here but with Qubes specifics other then already mentioned, and it looks I’m not the only one searching for pointers with this. It’s not that we’re lazy to manually set all the tweaks and preferences again, it’s just what the second sentence in this post says.

Regarding dom0, as per fslover’s link in order to get

some number of potentially compromised VMs (those restored from the untrusted system),

some number of clean, non-compromised AppVMs.

and then to compare them back to back, while both running. I see here still possibility of channel side attacks by running potentially compromised restored VMs, but the article itself doesn’t address this.
in the article, in Summary section it is said that Qubes provide:

… 2) ability to safely migrate select data from compromised AppVM to new VMs

which I’m not clear about how the data in a compromised VM isn’t also compromise, but I anyway keep this on mind, too.

Thanks once again for your time.