[qubes-users] "private.img", attaching and backups

Mailing Lists qubes-users
1

Hello everyone,

after some years, my qubes backup script became too outdated and doesn't work any more. For writing a new backup script, I have a few questions:

- I only plan to backup the userdata, "home" folder within vms. In recovery, I am fine with reinstalling qubes os itself and all template vms. I wish to take btrfs snapshots of /var/lib/qubes/appvms while some vms are still running. What blockfiles do I need to restore the vms "home" files? I see:
  private.img
  private-dirty.imng
  private.img.123@<timestamp>
Some years ago, it was not possible to mount the "'changes since vm-start' heap file". Will I lose all filechanges since the vm started, if I don't siut it down before taking the snapshot, and only backup one of those files? Will I be able to restore most of my files from the running vm when copying over all three of these "private" files?

- My idea is to attach all vm blockfiles to a dedicated backup-vm, mount the private.img (or the like) there locally, and rsync its fs content to a remote network location.
What would be a good way to efficiently present all dom0 vm blockfiles to that one backup-vm?
Attaching all private.img (or the like) blockfiles one-after-another to the backup-vm (seems easy to break)?
Or copying them all to one big blockfile in dom0, and attach that blockfile to backup-vm (much overhead)?
Or is there any way to attach the appvms folder from dom0 to the backup-vm, instead of attaching blockdevices (folder =! blockdevice)?

Thank you for any hints,

Stickstoff

I want to keep dom0 secure, so I like block-attach as a tool.
Also, I would only attach the data from a read-only btrfs snapshot, to secure the vms a tiny bit more.
The backup-vm has no other tasks than sending all data away to a remote backup destination, to keep its attacksurface small~ish.
Sensitive data, like passwordsafes, are locally encrypted in their respective VMs before backup.
In my scenario, I am more afraid of losing data than being attacked and having lowered qubes' security guards too much, so the top priority is an automated remote backup.

2

Hi

I dont use btrfs, but I do backup some qubes while they are running, by
mounting the private.img and private-snap volumes. I think this is what
you are proposing, and it will work fine. Mount the volume ro.
I use a disposable to take the backup of the qube, and spawn it for each
new volume. It works well, and I dont have issues.

private.img is the file that contains /rw for your qube.
The timestamped entries are backups of your private.img. You can revert
to these as you will.

I dont recognise private-dirty. Sorry.

3

The generic problem with backing up a "live" image is consistency:
With a journaled filesystem write ordering is important for recovery, but when mounting a live image read-only, the image may change while you read it (unless you made a snapshot before). In general I'd advise to backup properly unmounted images only. Those WILL work, while others MIGHT work.

Ulrich

4

[/quote]
But for frequent, rapid backups (like Time Machine), shutting down the
qube is not an option. You should use a backup tool that will pass by
such read issues. Eg zpaqfranz will add the file to the archive but
write a Warning.
I used to use snapshots, but in the time I've been doing this I havent
encountered any issues. I mean that I have been able to access and
restore files at any point of time, and *that* is the point of the whole
process.
If you want to create a snapshot and attach that, do so.