Todo misc about wyng-backup HOT 2 CLOSED

* Option to backup hot volumes (Qubes *-private-snap)

What exactly is missing for this option? I just did some crude testing and I seemed to be able to backup hot volumes without problems. I imagine there are a lot of stability issues lurking here, but is there something more fundamental, especially if the VM has run sync before the backup?

from wyng-backup.

@dmoerner It certainly works for volumes like dom0 root (i.e. non-guest volumes). Note that when qubes-backup makes a backup of a live VM volume, it uses the old at-rest version of the volume not the live one.

Although this applies to Linux VM guests in general, there is very little written on the subject of suspending guest filesystems for snapshots / image backups. And it appears this is not handled automatically for domUs/guests, so simply having Wyng back up the live vols will probably produce backups that will need fsck if/when they are restored. But I noticed that fsfreeze was made part of the util-linux command set in recent years. The manpage claims that is can stabilize a filesystem although I haven't tested it.

Volume naming:
If you point Wyng at the -snap volumes (the live volumes) instead, they won't exist if you backup while the VM happens to NOT be running. Wyng needs a way of knowing either a) naming convention for finding the two possible volume names, or b) a way to simply store the two volume names. A user workaround to handle it right now could be a cron job that snapshots whichever snap/non-snap volume was available to a vol name with a user-chosen suffix. Then configure Wyng to backup volumes with the new suffix.

from wyng-backup.