you can encrypt the volume and put snapshots on that. maybe the future of qubes-backup?
till then i use a script from dom0,
qvm-run backupkeeper "rm -rf QubesIncoming/*"
for i in `cat backuplist`;do qvm-run $i "qvm-copy-to-vm backupkeeper .";done
then rdiff-backup QubesIncoming /run/media/user/.../backups/rdiff
this way, the same drive can also keep appvm snapshots.
backupkeeper is just an appvm with no network access and a lot of space. the usb disks are setup with cryptsetup, ext4 and a backups folder owned by user. the first line is to get rid of old backups. qvm-copy-to-vm wont let you overwrite.
its no TimeMachine, and deleting and copying entire folders is inefficient. but does the job and easy to recover on any linux system.
would be nice to be able to initiate the file copy from dom0 and auto allow it. then it could run in the background.
> Thanks,
> Loren
im cleaning it up for general consumption. its a sync and inc style backup (thats just what i call it, im sure this style of back up has other names), meaning the appvms dont have direct access to the incremental backups. that way, malware can overwrite the past and you can laugh off ransomware.
heres the process in more detail.
1. install rdiff-backup (or use that script) in your chosen template vm, and make a backupvm. give it enough storage for all your other vms backups. to do this use the qubes vm manager, go into vm settings and set disk storage. since my online life is boring, 10 gigs is enough. most people here will want at least 100.
2. make your backups disks. $1 is the device. for this purpose, i usually dont bother with partitioning, and just use /dev/xvdi
#!/bin/bash
set -exu
cryptsetup -v --hash sha512 --cipher aes-xts-plain64 --key-size 512 --use-random --iter-time 5000 --verify-passphrase luksFormat $1
cryptsetup open $1 test
mkfs.ext4 /dev/mapper/test
mount /dev/mapper/test /mnt
df -h /mnt
umount /mnt
cryptsetup close test
then mount your new disk, and
sudo mkdir backups
chown -R user.user backups
you should keep at least two.
then, im dom0, keep a list of appvms you want to backup, and run this,
qvm-run backupvm "rm -rf QubesIncomming/*" # delete previous backup
for i in `cat backuplist.txt;do qvm-run $i "qvm-copy-to-vm backupvm .";done
youll have to accept a lot of copy permissions. when thats done,
mount a backup disk in backup vm and
backupvolume=`ls -d /media/run/user/*`
rdiff-backup QubesIncomming $backupvolume/backups
this last part could be replaced with any incremental backup, like rsync-time-backup. another possibility is duplicity for an online backup.
the above process is inefficient in that a full copy is made every time you make a backup. the only way i can think of to get around that would be to make a backup disk image for each targetvm and then attach all of them to the backupvm for the incremental backup. this would also be an easy way to exclude certain files like caches.
> What would be the costs/benefits of using VM snapshots instead of rsync?
> Would it even be possible to run an rsync script like the one above in
> dom0 that reached into the VMs? (I'm still learning the ins and outs of
> Qubes.)
you run commands in a vm from dom0, but you cant rsync across vms. you can also run commands in a vm from another vm, but you have to set up special permissions for that. see https://www.qubes-os.org/doc/qrexec3/
>
> Loren