Great. Decryption works and the decrypted volume is available in backup-vm.
create selective vms backup encrypted with verbose
The qvm-backup utility takes VMs to backup as arguments and supports a –verbose flag. Does that do what you’re looking for?
auto decrypt block device attached to backup-vm
The first step is to automate this part of your backup script with a configuration file in backup-vm:
qvm-run --pass-io backup-vm -- sudo cryptsetup open /dev/xvdi bk --type luks
You can configure Linux to automatically decrypt block devices with the /etc/crypttab file. Since backup-vm is an AppVM, you will need to persist /etc/crypttab.
Qubes VMs don’t create or use /etc/crypttab by default. You will need to manually create the persistent /etc/crypttab file under /rw/bind-dirs, as described in the paragraph that starts with “If you want to circumvent this process, …”, here. Follow these steps in a backup-vm terminal. Do not use
First, follow the Qubes persistence directions to create _ /rw/config/qubes-bind-dirs.d/50_user.conf_. Then, add this line to that file:
binds+=( '/etc/crypttab' )
Next, create the persistent /etc/crypttab.
$ sudo mkdir --parents /rw/bind-dirs/etc
$ sudo touch /rw/bind-dirs/etc/crypttab
Now add a line to /rw/bind-dirs/etc/crypttab to automatically mount the encrypted block device in backup-vm.
Earlier, you used /dev/xvdi as the encrypted block device. But that name isn’t guaranteed to exist in backup-vm. As I described in my first response, think about using one of the persistent names for your encrypted block device that you can discover with:
ls -R /dev/disk/*
After you’re done editing /rw/bind-dirs/etc/crypttab, restart backup-vm. Open a terminal in backup-vm. Does /etc/crypttab exist?
If /etc/crypttab exists, you can try attaching the encrypted block device from the USB device to backup-vm to see whether it mounts automatically. But don’t be too surprised if it doesn’t work, yet. You may need to encourage systemd to re-generate some unit files when backup-vm starts up.
This might seem like a lot of trouble when
qvm-run --pass-io works perfectly fine to mount the encrypted block device in backup-vm from dom0. But it’s important for at least two reasons:
It reduces script complexity
This way, you can remove a line of bash shell code. That’s less complexity and less risk of failure in the future.
It increases security
qvm-run --pass-io in dom0. This command passes unfiltered data from domU VMs to dom0, which could process that data. It’s the same as copying data to dom0. Qubes documentation recommends against copying data to dom0.