local and offsite backup best practices

[Jake]

howdy list,

i'm seeking some input on best practices when backing up qubes machines.

i've had a look at the documentation for backing up qubes installs (
https://www.qubes-os.org/doc/BackupRestore/ ) and the methods can be
summarized as:

- run qvm-backup in dom0 on VMs that are shutdown and either store it on
dom0, some target VM or an attached USB device

for episodic local backups, e.g. weekly backups, using an attached USB
drive is an acceptable option. however, i am unsure of how to best deal
with this when running a USBVM.

due to the way qubes' dom0 is setup without network, it is not clear to
me how to best configure offsite backup software. many offsite backup
systems will run on a live OS/VM instead of requiring that the VM be
shutdown, as with qvm-backup in dom0. automatic scheduled backups from
dom0 would seem to be a problem since it would require all VMs to be
temporarily shutdown while making a backup, e.g. shutdown once a night.
having to restart all the VMs on a qubes machine every morning strikes
me as real painful from the UX perspective.

any clues or insight on this topic would be appreciated.

regards,
jake

[cprise]

You can't backup all vms in one simple step if you are not mounting a
local backup drive directly in dom0 (which can be risky). So the key is
to use a single appvm (i.e. USBVM) for local backups which has little or
no customization (therefore its a vm not really needing backup and can
be replaced with almost no effort).

For remote backups, having netvm and firewallvm that are non-custom is
also ideal. On top of that, you should have a 'backupvm' appvm that can
make the high-level connections for whatever service you use (ssh, ftp,
etc). The backup process itself uses Unix pipes if you choose a vm as
destination. (In the GUI) you can choose backupvm as a target appvm,
then on the line right below type a command that will run in the vm and
receive the backup file as input.

So adding an ssh command will result in something like 'cat
backupDATETIME.tar | ssh' being run inside the backupvm. Of course you
would have to flesh-out that ssh command with connection parameters and
a way to handle the remote output; probably so it looks something like this:

ssh user@remotesystem 'cat >/path/backupDATETIME.tar'

Additionally, since dom0 /home/user is usually included in backups by
default, you could occasionally perform a backup of said
USB/net/firewall/backup vm(s) to a file in dom0. Then they will be
included (in a fashion) in your regular backups.

-

For automation, you could write a script to take the output of qvm-ls
and filter-out the vms you know cannot be directly backed-up. Then do
qvm-shutdown for the ones that are running, use the qvm-backup command,
and finally re-start the vms that were running before.

OTOH, searching for info about Xen live backups (of running vms) turns
up some interesting stuff that might be applicable to Qubes:

http://www.kh-soft.de/?q=node/22

[David Hobach]

For file-based backups or syncs you can also just define one backup VM,
mount all other VMs to that one using qvm-block in dom0 and do your
backup magic there. Of course you'll either have to place a lot of trust
into your backup VM or encrypt your files before.
And you shouldn't have too many AppVMs (> 10 or so) or you'll run into
some limitations as the current kernel doesn't support more than 20
mount points or so.

[Jake]

ah, thank you, this is very helpful and has got me thinking. i'll try to
get some scripts together and see what can be done. if the solution i
come up with is of decent quality, i'll share it.