Re: [qubes-users] Back up running VMs on btrfs

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Chris Laprise:
> On 02/21/2017 07:43 AM, Rusty Bird wrote:
> > Hi Chris!
> >
> > > On 02/20/2017 08:28 AM, Rusty Bird wrote:
> > > > A small qvm-backup wrapper script that handles running VMs by chrooting
> > > > into a temporary dom0 filesystem snapshot. The backed up data is the
> > > > same as if those VMs had just been killed, which seems to work fine for
> > > > the usual journaling/copy-on-write VM filesystems.
> > > >
> > > > https://github.com/rustybird/qubes-stuff/blob/master/dom0/bin/qvm-backup-snap
> > > IIRC, the best practice for backing up is to use a snapshot as the source.
> > >
> > > I was thinking that a simple ability to point qvm-backup to a snapshot path
> > > would be optimum for backup flexibility.
> > I misremembered that as involving a fair amount of refactoring.
> > Looking into it again right now...
>
> There is the issue of handling multiple pools or mountpoints (if they are
> configured), but as a personal modification to allow backing-up while
> running VMs I'm guessing it should be pretty easy. As long as everything is
> on one fs.

https://github.com/rustybird/qubes-core-admin/compare/snapdir implements
a new qvm-backup option:

--snapdir=SNAPDIR Specify a filesystem snapshot directory to back up
from. VMs are allowed to run while being backed up and
the destination VM is not automatically excluded.

But I don't know if it makes a lot of sense to submit this patch as a
pull request. It would have to be reworked for core3-devel anyway.

CCing qubes-devel

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJYrIU0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf4nkP/istS24pvQAAzfLAusMymUip
M6idbBoye4k5adtNHyjFvsYrGRCxxOFFNF05U99cMUYITVf6isi5Rmz3fsLpz3Eu
CUztp3WBnTUNsQTQJpxwgwgqjmoEQf8Dkh0Aude2K3Mz2ARBR1mawfpzegVg2OfX
CIotNrpVRRqOJHBQGup0o43EhftNnUXfkdobrG9j9QPYWMoLuKJF9EMEW/QQcmNu
CazD6/op3JiFoGUHH2Kg1KocoPxAVMD9pwJJNZUVsfkHtnRjxEfN0oTpkhvONHYj
cB3GS/hF5q7Rck7wR8nehCzLacJ6iC3O14Ed6Y5T3e7OvBU/17hC73y+bS+tEHWH
UBfpmbL58JumGWUysurai29XQAIpJr5BNUtYtXsBoWBcOV3Gfe0xAOkTPfu+8xJO
df9elpBkIurvqmjSrGxQO5kfe+GUVbC9RgDWa4cZ33ajyr76Bg8lY9b7yYabmQ8t
m+g/FEx9O2KnmAo12mYrE05d239auLWmCbCtT9rRZJ1WxVjggpqQXhduBwo90I7C
IUs78pxHo3pf2bI64QSEa3y5K5c+C7PaKZZfzFV+WnDV59kMsVrGrC1XeIxHQ7XT
cS6v6WmYYC7DSVN2J71vhTtptZl0ojWXdOTSuA3B8cgWhXJ9+o0cAkvJynL45neP
ci5Yr+rxubeZewJ7dWVM
=yKMm
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

In core3, every VM disk volume support "snapshot" operation (this is one
reason why LVM is default there). So every VM can be included in backup,
even if running (in fact the only missing piece is removing checking for
running VMs).
In fact, a running VM is using _snapshots_ of own volumes, not those
volumes directly (those snapshots are committed back to original volume
on VM shutdown - if applicable). This for example makes even easier to
implement template rollback feature.
The downside in the context of backup is that, the backup include VM state
from the time before the VM have been started, which may be long time
ago for long running VMs... On the other hand, volume filesystem wasn't
mounted then, so supposedly is in a clean state.

This may require some more thinking, but currently I'm working on a
totally different part of core3 and will come to backups in a week or
two.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYrLArAAoJENuP0xzK19cseZQH/R4bDlrKzUb5p2qpVMYW2H7V
aND/ENLEhil0ObPjFpoe76cSPQdDwUJNITX6DZt48UA1Evj2yQl599pPx53ZjEP0
qozV268JNDicAOSA+8qT7axQRLvz3zAhm040eg0dJ4Xa7qpmyAQlyAl5QoWsEVse
joCl47IUTZnxXXl1BJwJZqSYCDQ111pDkazJVvbDCdmuce8tS02Bia1w4Wtk7p2B
FekunvvaXHZeA4p1XLCH+KoXUdqLD8OY6EDJNeOl6UpP7u7sY3swfCypuknTd8R6
V3eNF10akT0gX1pWK3jde9V/uRqWAMwf/jLEqQmOoGEorl7ZUyugFBoBlPBymNw=
=HIZN
-----END PGP SIGNATURE-----