On Thu, Apr 06, 2023 at 15:22:10 +0200, lejeczek wrote: > Hi guys. > > Is there a solution, perhaps a function of libvirt, to backup guest's > storage and encrypt the resulting image file? > On-the-fly ideally. > If not ready/built-in solution then perhaps a best technique you > recommend/use? > I currently use 'backup-begin' on qcow2s, which are LUKS encrypted. libvirt's block code supports the raw+luks and qcow2+luks encrypted image formats with qemu. You should be able to use both for backups too: <domainbackup mode='push'> <disks> <disk name='vda' type='file'> <driver type='qcow2'/> <target file='/tmp/backup-test-images/backup-vda.qcow2'> <encryption format='luks'> <secret type='passphrase' uuid='d5c7780c-80c4-45eb-bee9-9fbbc1f3847c'/> </encryption> </target> </disk> </domainbackup> Another option would be to use an encrypted device-mapper device via the block backend. Lastly if you need any other storage format the 'pull' mode of backups exposes a (optionally TLS-encrypted) NBD socket from where a client application can pull the blocks for backup and store them in any way it wants.

On Fri, Apr 07, 2023 at 19:42:11 +0200, lejeczek wrote: > > > On 06/04/2023 16:12, Peter Krempa wrote: > > On Thu, Apr 06, 2023 at 15:22:10 +0200, lejeczek wrote: > > > Hi guys. > > > > > > Is there a solution, perhaps a function of libvirt, to backup guest's > > > storage and encrypt the resulting image file? > > > On-the-fly ideally. > > > If not ready/built-in solution then perhaps a best technique you > > > recommend/use? > > > I currently use 'backup-begin' on qcow2s, which are LUKS encrypted. > > libvirt's block code supports the raw+luks and qcow2+luks encrypted > > image formats with qemu. You should be able to use both for backups too: > > > > > > <domainbackup mode='push'> > > <disks> > > <disk name='vda' type='file'> > > <driver type='qcow2'/> > > <target file='/tmp/backup-test-images/backup-vda.qcow2'> > > <encryption format='luks'> > > <secret type='passphrase' uuid='d5c7780c-80c4-45eb-bee9-9fbbc1f3847c'/> > > </encryption> > > </target> > > </disk> > > </domainbackup> > > > > Another option would be to use an encrypted device-mapper device via the > > block backend. > > > > Lastly if you need any other storage format the 'pull' mode of backups > > exposes a (optionally TLS-encrypted) NBD socket from where a client > > application can pull the blocks for backup and store them in any way it > > wants. > > > That works as I hoped, nice & smooth, I've not had the right xml syntax. > Are there any docs with more details on the other two alternatives? > many thanks, L. Well, the backup to a (externally provided) device mapper target is quite straihtforward: <domainbackup mode='push'> <disks> <disk name='vda' type='block'> <driver type='qcow2'/> <target dev='/dev/mapper/crypt-backup-target'/> </disk> </domainbackup> The pull-mode backup with NBD where you handle the encryption in the client program (not provided by libvirt, but you can have a look at e.g https://www.libvirt.org/apps.html#backup or oVirt which both implement a NBD backup flow). To setup a backup in pull mode, simply use: <domainbackup mode='pull'> <server transport='tcp' name='localhost' port='1234'/> <disks> <disk name='vda' type='file'> <scratch file='/tmp/backup-sctratch-vda'/> </disk> </disks> </domainbackup> To setup TLS to encrypt the transport you can use tls='on' and need to setup the TLS certs. Have a look at the docs for 'server': https://www.libvirt.org/formatbackup.html