The one main reason one’s would love wyng-backup is because if supports send deduplication, and whole archive deduplication. On top of that, it is really efficient into only sending differences on volumes (let them be private (qubes volumes) or root (template volumes).
What is deduplication, one might ask?
It makes sure that no other block previously having been part of the archive is being saved again.
Why does it matter to Qubes users?
Because Qubes OS pushes users to clone and specialize Templates and qubes.
You can do this, but in my case at least it’d be a waste of time as backing up AppVMs is minimal (there’s only a tiny amount of data on them). So the main gain from such a thing would be for backing up templates; which I don’t expect to do very often anyway (immediately after regenerating or updating them, and I’d save the previous copy long enough to be sure I didn’t break things in regenerating them, then get rid of it).
Nevertheless, I’m glad you’re bringing this up, because for someone who has a lot of data in their AppVMs, this might very well be just what they need.
Are there any Wyng users out there?
Looking for input on your experience.
In particular:
Can you review the contents of each archive file?
Can you restore specific files from a set date?
The process is a bit manual as of today.
To restore a specific backup state, the preferred way is to clone the vm/template first, and then have wyng receive the content, with sparse-write mode, so that the destination volume is rewritten in place to that specific state.
Then you boot that qube into that restored state and extract the data you want, or use qubes-block manual tricks to have that volume passed to a dvm and extract the files needed from there back where you need them.
One can then use whatever tool desired to compare states of mounted disk images and compare them, ex with meld if desired. That is what I did several times to compare dom0 changes between different states, or between backups of templates or qubes content.
Wyng is doing differential backup of “snapshots”. It doesnt care about “files” but blocks.
@unman To restore a specific file is not wyng scope.
wyng keeps backups differences, and relies in hardlinks for block level deduplication. So if one decides to restore a volume to a specific date without specifying an alternative destination volume, that user will have that volume reverted to what it was at the moment of backup. We are talking here about the volume specified in the backup, which requires minimal understanding of qubes rotation mechanism.
For example, a user could restore a running qube private volume under the logical private volume. Have that qube shutdown. And use qvm-volume to revert the state to what qubes rotates to, which will become its more recent back volume.
Without current qubes integration as of now, the best is to restore that volume session into a cloned qube in sparse-write mode (writing only the different blocks and adjusting volume to be as in backuped state directly in that lvm) and deal with that qube as it was at that date.
@tasket proposed implementation of a fuse backend to be able to map a device corresponding to a reconstructed image. Thinking of such qube implementation would permit to have qube deal in a dispvm to create metadata on backuped content and maybe even present such meta-data to be included under wyng metadir content. Speculating here. But no, as of today, I repeat, wyng has no idea of what files are under the backups. Just a set of blocks that changed since last backup, and a specific volume will point to other shared blocks of deduplicated, otherwise its archive will contain compressed data of those blocks.