@kenosen PS – You can create an /etc/wyng/wyng.ini file to have it remember settings like --authmin (see example in the Wyng Readme). However, newer versions of Wyng will default to 2 minutes so that util wrappers can call it repeatedly without causing prompts or KDF delays (the delay is still present if you automate with --passcmd but don’t use --authmin).
Thank you again for the detailed response. I’ve decided to work within LVM as that is what the installer chooses by default, and the fewer tweaks I have to make are usually safest 
nevertheless, and in direct opposition to what I just wrote, I resized the metadata pool.
Per Wyng issue 148, I appreciate you bearing with me through what became a thought experiment and moment of edification. We’ll continue the discussion wherever appropriate. And a link, where I ask a few more questions about wyng-backup capabilities, for those following along.
@unman I take the liberty to answer here. As of now, wyng-backups can only restore a state from a backup to another lvm. The way I did this in the past is basically cloning a qube to to another one and mounting as per emergency recovery doc to restore data.
You can loop mount those two LVM in r/o to a dvm and compare directories with your favorite tools, and rhen from that qube, send the file you want to keep with qubes tools to desired VM.
I thought about this post when reviewing my past conf (a lot of things evolved from 2021) but I used this a lot in the past to investigate changes under dom0 from this https://youtu.be/1u9Q6ANU51E?t=755&si=kdkaCvd_KtyA2BAL
By cloning a qube, you can then sparse-write only the diffs from backup to that LVM which is really fast. This is really useful to compare between any two states, but as of today requires manual steps because not integrated. Secure boot support · Issue #4371 · QubesOS/qubes-issues · GitHub
@tasket opened this issue FUSE filesystem for mounting archives as volumes · Issue #16 · tasket/wyng-backup · GitHub which seems to be exactly what you are looking for @unman. It is to be reminded as per past discussions in other threads and issues I remember on top of my head that wyng is block level based, and what you are talking about is file level exposure, therefore you have to attach those block devices to a qube for that qube to abstract the block level and expose files. Mounting such block devices can easily be made to expose files to be compared against and decide which one to keep.
I would encourage to discuss your need in the referred issue. You might have alternative strategies or ideas to share on implementation there, maybe.
It is to be noted, that current snapshot rotation mechanisms of qubesos with LVM merge options can be abused to even restore a dom0 backup to be used upon reboot (when volumes are deactivated). I used that a couple of times in the past as well to restore even dom0 to desired state. Again stating Secure boot support · Issue #4371 · QubesOS/qubes-issues · GitHub here: if os layer/states (config, logs, etc) were separated, one could restore even dom0 state to a known good one. But we are not there yet.
The Wyng Backup final beta is out! After this, Wyng v0.8 will have a release candidate before going to general release.
If your data resides in disk images or logical volumes, Wyng may be the quickest incremental backup available with speeds similar to btrfs-send – even when the backup resides on a regular posix filesystem!
Also released… wyng-util-qubes v0.9 beta which integrates Wyng with Qubes OS and now supports VMs stored on Btrfs, XFS and thin LVM. Use wyng-util-qubes to run Wyng for backup & restore operations, automatically restoring VMs settings along with data.
Edit: For those needing to verify the code before installing, my PGP key fingerprint is: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
#wyng backup #linux #vm #containers #qubesos
9 Likes
great, is there a community guide about wyng and wyng-util-qubes yet?
I saw a guide that used Wyng in conjunction with salt, but have not seen a wyng-util-qubes guide. The latter became fully functional (for lvm) only last year so that makes sense.
Installation and use are pretty simple though: Install 2 packages with qubes-dom0-update python3-zstd python3-pycryptodomex then git clone and verify the two github repos (wyng-backup and wyng-util-qubes). Each runs only from a single Python source file; copy each one to dom0 (they should be in the same dir) and chmod +x wyng wyng-util-qubes.
Then create a Wyng archive using wyng arch-init --dest=<URL> and use wyng-util-qubes backup <qube1> <qube2> --dest=<URL> to backup VMs. This should all be covered in the Readme.
One thing that would be good to expand upon in a community guide is how thin LVM can require more metadata space when you start making more snapshots (Qubes’ installer had to deal with this, IIRC). Adding Wyng snapshots to the system means its best to extend the LVM metadata further; this can be done manually with lvextend --poolmetadatasize.
1 Like
I think you once noted that 3x the size of the vm pool is a good place to start for resizing. Here’s the guide, but doesn’t use wyng-util-qubes:
Does this mean that widespread deployment will set in, as soon as it went to general release?
Btw, thanks for the tremendous work!
What are you supposed to do if you for some reason are forced to make a new archive?
I just keep getting the message that the snapshot belongs to a different archive, and I need to remap. I tried to remap, delete, clean, delete the tick files, but I just keep getting the same message.
I’m using brtfs if that makes a difference.
1 Like
@kenosen 3X was what I started using years ago (I think Qubes 4.0?) before Qubes’ installer started extending it. But recognizing that Qubes today creates more snapshots itself, I still recommend 3X.
I really don’t know. But I suspect that the more containers and even flatpak-like schemes (with supposedly read-only-like root fs) increase in popularity, the more appealing it will become. On Linux, both CoW filesystem installs and the use of disk images / lvs on top of them are becoming common; that is the right environment for Wyng being useful.
@renehoj Sounds like an interesting bug if that’s the case. I’m able to wyng send from Btrfs-based disk images to different archives without issues. Wyng only limits you to one archive at a time on LVM, so maybe your system has an LVM pool in addition to Btrfs? And the tick/tock naming isn’t used at all on Btrfs. Also, --remap send should always clear the issue and a fresh LVM snapshot will be assigned to the current archive.
FWIW, 
it may be possible in the future to assign more than one archive ID tag to single snapshots; this would prevent the need to use --remap in many cases.
1 Like
Got it working, the .tick files wasn’t deleted. You are right about it being lvm, I thought I had installed both my systems with brtfs.
python3-pycryptodomex is available by default in QubesOS 4.2, so only python3-zstd needs to be installed additionally; btw.: is it required for wyng-util-qubes or just optional for best performance?
Also, would you mind putting your GPG fingerprint on some of your social media for double checking?
Thank you for your work, I look forward to testing it soon!
python3-zstd isn’t required, but without it you’ll be limited to using either zlib (gzip) or bzip2 compression which are generally much slower than zstandard. Also during a system recovery process using Wyng, its a good idea to keep it on your list of things to install in case the archive you have to restore from is compressed with zstandard (aka zstd).
My PGP key fingerprint is BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
3 Likes