-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, Apr 08, 2021 at 04:07:07PM +, 'blxxd' via qubes-devel wrote:
> My use case is migration between devices, I create backup on primary laptop
> and restore it on secondary. To achieve this I remove existing VMs first and
> then restore backup because
Yes, this is how we envision using backup for this purpose. For disaster
recovery, we also have an option in the installer to avoid creating any VMs -
this way you get empty system you can restore your VMs into.
But note the backup restore has also another important use case -
restoring some VMs because you just want to retrieve some data from them
(for example you deleted too much, or need to access some older version
of a file). In this case is it very undesirable to replace your current
VM with the old copy - rather restore under a different name and likely
remove that restored VM after you retrieve data from it.
> if I restore backup first I will have to rename almost 20 qubes manually
> which is virtually impossible to do on a weekly basis.
> It makes me feel uncomfortable to remove VMs before restoring backup so I'm
> looking for ways to avoid this. Now I see two solutions:
> 1. Write a tool that will preserve old ones under different names and rename
> restored VMs to original names
> 2. Modify backup restoring process so existing VMs would be renamed and not
> restored ones
>
> I like the second one but don't know if there is any downsides. Can you share
> your thoughts on this? Thanks
Renaming VM may have huge implications. Here are example issues:
- for example if that is a template - what should happen to already
existing VMs based on this template? should they be referring to now
renamed template? or the just restored one?
- similar question to network relation - if you restore sys-firewall,
should existing VMs refer to the old one or the new one?
- you cannot rename running VM (which may include the VM you use to
access the backup archive itself) - in this case, you cannot restore
the backup of such VM other way than restoring to a different name...
- if you rename existing VMs during restore, if restore fails for any
reason you could end up with a mixed set of old and new VMs -
something even harder to recover from
So, I think for your purpose the first approach would work better.
Because you can shutdown all the VMs at this point, but also have clear
expectations about the final state. If you don't need to restore any VM
that is running during the restore process itself, you could even
rename them before restoring to avoid the conflict.
Some option to make this use case easier, is to have a mass-rename tool,
that you can apply before restoring the backup. Currently full rename is
implemented in GUI tool only, which makes it hard to automate.
If you worry only about data and not VM settings, then there is also
another possible option to implement: our storage subsystem (all but the old
"file" pool) support volume revisions you can rollback to. By default
they are limited to one revision back (and a revision is created each
time you shutdown a VM), but it is configurable (revisions_to_keep
parameter, see qvm-pool and qvm-volume tools). Now, restoring a
conflicting VM could restore the data as a new revision of a storage
volume. Then, if you don't like that, you can easily revert to the old
one. While technically possible to implement such approach, it also has
its own drawbacks:
- this applies only to data, not metadata (VM settings etc)
- reverting to older revision is not reversible (you cannot switch back
and forth)
- you cannot start both old and new versions at the same time (to copy
data between them for example)
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmBvQUEACgkQ24/THMrX
1yy1MwgAlK5OPkgW0eX+121eGEhL4M51fcY/M8NlcyMNA7vCQ46slDr5MSVCRG70
WAKrmnz3EYbODPPJbom0i6Iu+r+dm17eaZ5/l0gyX3WbymPXe/GGl6vOVImPFIOK
lyYkcZ2c2peDv2KTuAPcU2EhcgVUHQxxEe66t3TEorWLg99MtPj7yH6XeBOmkZgM
vYAlThFtEImhZfEi16Df6NkZK31WxfQFDcgEkQd1jser0n9/tINK1xw3S+SB9TML
cmjP1xJVbZcHfJ5eAGI6XLE2UAW3t5enDLcSrBSL796a1heSXKNMIZgSLXCaUKh1
Oa+K9H6MW8DWyF074GKv5UG0WzTkbg==
=rV6p
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/YG9BQK3bsS/iAYHT%40mail-itl.
