On 4/1/19 6:36 PM, 'awokd' via qubes-users wrote:
Ryan Tate wrote on 4/1/19 7:54 PM:
On Apr 1, 2019, at 2:33 PM, Ryan Tate <ryant...@ryantate.com> wrote:
Now I see there is a folder in my dom0 home dir called
‘home-restore-2019-04-01-etcetc’.
But what do I do with this? I just have to manually figure out what
files are important? :-\
I just sort of methodically copied over anything that seemed important
and rebooted which seems to get me most of the way there.
I would like to say, I really think the wrong decision was made here:
https://github.com/QubesOS/qubes-issues/issues/2271
https://github.com/QubesOS/qubes-issues/issues/1106
The rationale for not actually restoring dom0 when dom0 is requested
to be restored seems to be:
1.User may be restoring to a different machine from the original,
which could obviate e.g. monitor settings. User can’t simply avoid
restoring dom0 in this situation "because it contains some files and
scripts that I need” (quote from issue 2271).
OR
2. user may only restore some VMs and then the dom0 restore will
create false menus (issue 1106)
I would argue, if you ask to restore dom0, then dom0 should be
restored (truly, not by copying over a directory, which is not a
“restore”). Any glitches due to, for example, restoring dom0 to a
different machine, are the responsibility of the user. User may also
need to handle restoring dom0 with only partial vm restore, for
example by purging appmenus (although ideally the restore process or
architecture of Qubes would make partial restores happen more smoothly).
If the wish is not “restore” but rather to copy some files — “some
files and scripts that I need” — then it is up to the user to transfer
these files by the usual mechanism.
IMO Qubes has allowed the definition of “restore” to become a bit
corrupted. To restore is not just to copy a directory and let the user
fend for themselves. When I “restore”, the original state should
largely come back. e.g. app menus in vms, xfce panel particulars,
desktop particulars, etc. If I want something different, for example
only to copy some settings over, it should be up to me as a user to
make that happen. If the restore is imperfect, that is OK — it would
be better to have an imperfect restore (with, for example, some
phantom menus) than to have no restore at all, from the standpoint of
user expectations, judging purely from myself.
These seem like reasonable points though for visibility & tracking, it
might be better to paste them directly into one of those issues.
The current method prevents an unsafe restore in the event that the
system was reinstalled due to a compromise (or suspicion thereof). This
change was made shortly after Qubes project started promoting the idea
of "paranoid mode" restore, with which it fits very well.
In any case, the object for qvm-backup* isn't to save/restore everything
about dom0 since it only stores /home. And moving these files out of the
restore folder is relatively easy, if the user chooses.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/3ab58309-e8c4-0576-9fd8-3f2c42a3f0da%40posteo.net.
For more options, visit https://groups.google.com/d/optout.
