On 3/22/20 7:11 AM, [email protected] wrote:
On Sun, Mar 22, 2020 at 11:57:38AM +0100, haaber wrote:
Assuming you didn't make backups before the crash: You need to have a
running Qubes system to backup VMs the normal way.
Does that mean Chris, that in case of a disaster, there is no way to
backup your data "by hand" (booting a live linux, opening the luks ..)
because of a "thin pool" mess? That sounds in first hand like a strong
argument against the use of thin pools! As you know a lot about thin
pools, could you please comment on that, Chris?  thx, Bernhard

thin pools are plain linux tech, nothing qubes specific.
and you can back them up in whatever way you want, from whatever
distro/system you want.
or not back them up at all, and simply attach the disk to some
other system.

it is not trivial to use the _qubes_ backup tooling outside
of a qubes system.
but besides that, they are just blockdevices with filesystems inside.

Right. Another way to phrase my advice is that the "vm*-private" volumes are simply disk images and contain all the data for regular appVMs. For templates and standalone VMs, the "vm*-root" volumes are also a part of the VM's data. Backing these up can be pretty simple, since they are block devices accessible from /dev/qubes_dom0 and you can use 'dd' or 'dd | gzip' or whatever. You could even use my backup tool (wyng).

The perceived "mess" is actually rather organized, and has nothing to do with LVM thin pools. If you had installed Qubes with non-LVM storage, you would still have separate disk image files for each VM. You can make the volume list more readable with 'lvs | grep private' to filter out non-private volumes.

Of course there is Qubes-specific metadata (i.e. the Settings dialog for your VM) in /var/lib/qubes/qubes.xml and maybe firewall.xml files in the subdirs there. But these should only matter if you changed VM settings in the Settings dialog or via 'qvm-prefs' or 'qvm-firewall' commands, and even then many settings like 'Memory' and 'Applications' are trivial.

Finally... It should be possible to write a recovery script for this situation, which presents the user with a list of VMs to recover and optionally allows you to recover the contents of /var/lib/qubes.

--
Chris Laprise, [email protected]
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ab71a53a-f7ab-d4d3-7138-349d5d03bba3%40posteo.net.

Reply via email to