Back up running VMs on btrfs
56 views
Skip to first unread message
Rusty Bird
Feb 20, 2017, 8:29:06 AM2/20/17
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Something for the btrfs crowd:
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
Also pasted below. POC, may ruin absolutely everything, etc.
Rusty
#!/usr/bin/sudo sh
#
# qvm-backup wrapper that can handle running VMs stored on btrfs dom0.
# Usage: qvm-backup-snap <qvm-backup argument>...
set -e
tmp=$(mktemp -ud /var/tmp/qubes-backup-snap.XXXXXX)
btrfs subvolume snapshot / "$tmp"
trap 'btrfs subvolume delete "$tmp"' EXIT
sed -e 's/^\( *\)if vm.is_running():$/\1if False:/' \
-i "$tmp"/usr/lib64/python2.7/site-packages/qubes/backup.py
for d in /dev /dev/shm /proc /run; do mount --bind $d "$tmp"/$d; done
chroot "$tmp" su -s /usr/bin/qvm-backup - "$SUDO_USER" -- "$@"
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJYqu8RXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf8v0QAI4eRTXSAkHAbL3+Z3K94nbU
aEaG0YzyMA6r9byo8idpsvuR/gMPhrcLiBdB+bvlMRuQ8tx1GH/8YnGVdb3/8ccr
QcrDAv9abWOUbCRbLxP6cckE7pNYwBys7DQVqkMvN3irkxHnNWGjtczMbJJ+B+gi
R+LxYXJnz4Hn6392HXSqbAv1PPyNGymYLqSJfzH30pdvTt6QICjOH4DHH5yfGRqx
o3iablnBb9EmbSCa8Fn8mdtu/CcP58QgVwUrGA2Y15JE2ViAS2EVpxX5Ah+e0RpC
WzjJC9t73SI8/1549BvxHMf5aInJbXBmn/hbmpTTnFacRkXn7aPSvA7dUZrQvhqP
FcCYlBZ6LO2H1rxpcaI7/ppLaqNwjzuXs6OW6Luw96k2yaR+iI5N4JCIhHUFagBR
2KaU2wTi4yKNJD9ZD0lGCpjDLdpECrDKHHC56ZRawYQS8JwUkjF7vwD2UJTzT7HN
r6pQR11lpSgdbbWAdqQxH2VKFX6bwEN4gvl52VG7B6+/hTMb5PdXMp/2h+gI1biK
Lw0roF9QyYMmP96JWXtAoO0eC1IhGVDVqR+3kGXFRwxrkQCrZP/jt+fSllYpAWZp
JfWNoB38rZpqNyZdOEGC4Odw0iiw7BeSKeRuCDhWiSJkeCUtVyohZI7rXNLcCKdV
fIYc8ix5g9B1gQbFYJNd
=imFn
-----END PGP SIGNATURE-----
Hash: SHA512
Something for the btrfs crowd:
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
Also pasted below. POC, may ruin absolutely everything, etc.
Rusty
#!/usr/bin/sudo sh
#
# qvm-backup wrapper that can handle running VMs stored on btrfs dom0.
# Usage: qvm-backup-snap <qvm-backup argument>...
set -e
tmp=$(mktemp -ud /var/tmp/qubes-backup-snap.XXXXXX)
btrfs subvolume snapshot / "$tmp"
trap 'btrfs subvolume delete "$tmp"' EXIT
sed -e 's/^\( *\)if vm.is_running():$/\1if False:/' \
-i "$tmp"/usr/lib64/python2.7/site-packages/qubes/backup.py
for d in /dev /dev/shm /proc /run; do mount --bind $d "$tmp"/$d; done
chroot "$tmp" su -s /usr/bin/qvm-backup - "$SUDO_USER" -- "$@"
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJYqu8RXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf8v0QAI4eRTXSAkHAbL3+Z3K94nbU
aEaG0YzyMA6r9byo8idpsvuR/gMPhrcLiBdB+bvlMRuQ8tx1GH/8YnGVdb3/8ccr
QcrDAv9abWOUbCRbLxP6cckE7pNYwBys7DQVqkMvN3irkxHnNWGjtczMbJJ+B+gi
R+LxYXJnz4Hn6392HXSqbAv1PPyNGymYLqSJfzH30pdvTt6QICjOH4DHH5yfGRqx
o3iablnBb9EmbSCa8Fn8mdtu/CcP58QgVwUrGA2Y15JE2ViAS2EVpxX5Ah+e0RpC
WzjJC9t73SI8/1549BvxHMf5aInJbXBmn/hbmpTTnFacRkXn7aPSvA7dUZrQvhqP
FcCYlBZ6LO2H1rxpcaI7/ppLaqNwjzuXs6OW6Luw96k2yaR+iI5N4JCIhHUFagBR
2KaU2wTi4yKNJD9ZD0lGCpjDLdpECrDKHHC56ZRawYQS8JwUkjF7vwD2UJTzT7HN
r6pQR11lpSgdbbWAdqQxH2VKFX6bwEN4gvl52VG7B6+/hTMb5PdXMp/2h+gI1biK
Lw0roF9QyYMmP96JWXtAoO0eC1IhGVDVqR+3kGXFRwxrkQCrZP/jt+fSllYpAWZp
JfWNoB38rZpqNyZdOEGC4Odw0iiw7BeSKeRuCDhWiSJkeCUtVyohZI7rXNLcCKdV
fIYc8ix5g9B1gQbFYJNd
=imFn
-----END PGP SIGNATURE-----
Chris Laprise
Feb 20, 2017, 2:41:53 PM2/20/17
to qubes...@googlegroups.com, Rusty Bird
On 02/20/2017 08:28 AM, Rusty Bird wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Something for the btrfs crowd:
>
> 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
>
> Also pasted below. POC, may ruin absolutely everything, etc.
>
> Rusty
>
IIRC, the best practice for backing up is to use a snapshot as the source.
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Something for the btrfs crowd:
>
> 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
>
> Also pasted below. POC, may ruin absolutely everything, etc.
>
> Rusty
>
I was thinking that a simple ability to point qvm-backup to a snapshot
path would be optimum for backup flexibility. There would be no loose
ends, such as having VMs with newer data sitting in a snapshot, and no
chroot needed. And it could work with LVM snapshots also.
Alternately, qvm-backup could simply check the filesystem type for each
VM folder, and if its Btrfs do an instant reflink-copy to a temporary
backup folder just before performing the backup.
Chris
Rusty Bird
Feb 21, 2017, 7:44:17 AM2/21/17
to Chris Laprise, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Chris!
Hash: SHA512
> 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.
>
> I was thinking that a simple ability to point qvm-backup to a snapshot path
> would be optimum for backup flexibility.
Looking into it again right now...
Rusty
-----BEGIN PGP SIGNATURE-----
iQJ8BAEBCgBmBQJYrDX0XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfOgEP/RY9ILKoJMU1a+rb1xun6dCw
g6RjOMKJrDvvdY7UA+y2+e6qDu/NK5ZY4WNEedo6GcX56NYfGiLZ60YxlFF0bSfj
uIeIpmfWdLsaVkcCDEW+Q7XJLu/5y+a8lJG/Jz7fAsYZDAynV06v8V1zhvgL+58W
IDAlgE6bofcbJgzM033z9LUYPr032cDC0FL9BBJsS04VQn/Dny2yM0W1fJPHcKcD
MNyf6sR4tBmDsKjIILikDPCMMu/LhaRabRGja2Fio98ZFhi8zsEibsA4OEtE8zQy
pY15NPGLUmGfvce8bLX4qhetfY0+Qy2QbM5+px7bWQDUO0XS+6dGLfbq4rltVmpd
osB4E9ChSa+NOA1qdgicFkTVxyLL+I0X0TP+WbJ8jznbMKkLfy5KuFvbr+BrFvCb
7pOofRx68qjalWeguN+l9bKGaPSrqnW0SNxdjgWroDox4lyA6iwCZCetxT7UySXQ
n14jFkfZ1WCkYAmKj0C6dtnnJMhIrSYwhBX4fqyMpquAjh1m1nBaZZhqBPPgrHyf
7d1PNFKSFJoFU1dMKNxhFZZ1NcLXgXjHniGuutcNFtLvyw3k7sNoOruIUH7X5gN8
95qgxbuTxPX1PET2mA7xCZuqX8E3+II4WxwrU2C6YFlIMjKiQYR6cRaU69H96PQT
CvMW24kYVwuiT0tS7H8X
=Rq1r
-----END PGP SIGNATURE-----
Chris Laprise
Feb 21, 2017, 11:49:24 AM2/21/17
to qubes...@googlegroups.com, Rusty Bird
On 02/21/2017 07:43 AM, Rusty Bird wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> 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...
>
> Rusty
There is the issue of handling multiple pools or mountpoints (if they
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> 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...
>
> Rusty
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.
Chris
Rusty Bird
Feb 21, 2017, 1:22:02 PM2/21/17
to Chris Laprise, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Chris Laprise:
Hash: SHA512
> 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...
>
> > 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
> 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.
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
Feb 21, 2017, 4:25:05 PM2/21/17
to Chris Laprise, qubes...@googlegroups.com, qubes...@googlegroups.com
-----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-----
Hash: SHA256
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-----
Reply all
Reply to author
Forward
0 new messages