mounting a disk image or volume in app-vm, fast backups

[pixel fairy]

how do you attach an image file to an appvm?

what would you recommend for for resizable, or ideally, automatically resizing volume for this?

the idea is to attach an image an appvm, rsync the data you want to backup. then remount it in a dedicated backupvm which only runs rdiff-backup to an external disk. that way, the backup is fast (rsync and rdiff) and is protected from any malware trying to write to the past, and can be done without having to shutdown any vm.

[Unman]

qvm-block -A allows you to attach an image file to a qube.

[Connor Page]

On Monday, 14 November 2016 18:52:27 UTC, pixel fairy wrote:
> how do you attach an image file to an appvm?

qvm-block -A <vm-name> <device-vm-name>:<file>
for your purpose the file or volume can be in the backupvm.

>
> what would you recommend for for resizable, or ideally, automatically resizing volume for this?

lvm or btrfs but inside an image file in dom0 which kind of removes any advantage of resizable volumes. parsing partition tables and filesystem metadata in dom0 should be avoided.

>
> the idea is to attach an image an appvm, rsync the data you want to backup. then remount it in a dedicated backupvm which only runs rdiff-backup to an external disk. that way, the backup is fast (rsync and rdiff) and is protected from any malware trying to write to the past, and can be done without having to shutdown any vm.

you may get inconsistent backups. it would make sense to stop it temporarily in a consistent state and then send the private image from dom0 to the backupvm. this should work work full backups. partial backups would probably have to be done your way.

[Connor Page]

On Monday, 14 November 2016 19:24:06 UTC, Unman wrote:
> qvm-block -A allows you to attach an image file to a qube.

BTW, what's the correct way to detach one image file? it's not mentioned in the man page :(

[Unman]

qvm-block -A dst src:/home/user/foo.iso

Creates /dev/xvd[i,j..] on dst

To detach, use:
qvm-block -d dst -f xvd[i,j..]

That is, use -f to specify the device name

[Chris Laprise]

Using btrfs as the dom0 filesystem (or a btrfs volume added to a dom0
pool) could enable the advantages being sought here. Using either
snapshots or reflinks, you can create an offline copy of the VM's
private.img, and then attach that to the backup vm. This eliminates the
first rsync step.

Chris

[pixel fairy]

that would be faster :) but, reinstalling and restoring from backups would take a long time. maybe i could run it overnight.

in the mean time ill try sparse or qcow2 images since those automatically grow when needed.

> Chris

[pixel fairy]

On Monday, November 14, 2016 at 5:20:57 PM UTC-5, pixel fairy wrote:

> in the mean time ill try sparse or qcow2 images since those automatically grow when needed.

turns out qcow2 doesnt work, which is a shame given that you can move them across filesystems and preserve their "sparseness". but, for anyone else who wants to do this

somvm:~$ qemu-img create myimg.img 10G
dom0:~$ qvm-block -A targetvm somevm:/home/user/myimg.img

given that it can "reach in" the backup vm could simply mount from within after after syncing.

[Chris Laprise]

On 11/14/2016 05:20 PM, pixel fairy wrote:
> On Monday, November 14, 2016 at 5:09:41 PM UTC-5, Chris Laprise wrote:
>> Using btrfs as the dom0 filesystem (or a btrfs volume added to a dom0
>> pool) could enable the advantages being sought here. Using either
>> snapshots or reflinks, you can create an offline copy of the VM's
>> private.img, and then attach that to the backup vm. This eliminates the
>> first rsync step.
> that would be faster :) but, reinstalling and restoring from backups would take a long time. maybe i could run it overnight.

Or depending on your config, you could create a separate btrfs
partition. IIRC, Qubes lets you place VMs on other volumes.

If you already have ext4-on-lvm that might work, too. Make a snapshot
volume then use qvm-block on that.

Chris