Wyng for Noobs

This guide is intended to enable people who are not particulary comfortable with the command line to use Wyng Backup, which is much faster than the official backup tool due to its support for “deduplication”.

Set up:

Install

Start by downloading the most recent release for wyng-backup here and wyng-util-qubes here.

Verify the integrity of both of your downloads by following the instructions provided. It is best practice to verify a PGP key by comparing its fingerprint to a second source before trusting it: after importing the developer’s PGP key, run gpg -k to output its fingerprint, and make sure that it matches this forum post.

Finally, we will copy both downloads to dom0. In the dom0 terminal (Qubes menu > Other > Xfce terminal) run the following commands, replacing the path to the downloads as appropriate (depending on where your downloads are stored and what version you downloaded):

# Lines preceded by a # are a comment
# Copy wyng-backup from personal to dom0

[user@dom0 ~]$ qvm-run --pass-io personal 'cat /home/user/QubesIncoming/disp4099/wyng-backup-0.8beta6/src/wyng' > /home/user/Downloads/wyng

# Copy wyng-util-qubes from personal to dom0

[user@dom0 ~]$ qvm-run --pass-io personal 'cat /home/user/QubesIncoming/disp4099/wyng-util-qubes-0.9beta1/src/wyng-util-qubes' > /home/user/Downloads/wyng-util-qubes

# Install dependencies

[user@dom0 ~]$ sudo qubes-dom0-update python3-pycryptodomex python3-zstd

# Copy both to /usr/local/bin
[user@dom0 ~]$ sudo cp -a /home/user/Downloads/wyng /home/user/Downloads/wyng-util-qubes /usr/local/bin

# Make both executable
[user@dom0 ~]$ chmod +x /usr/local/bin/wyng*

Configure

We will now make a configuration file, as described by the docs.

# Make the directory
[user@dom0 ~]$ sudo mkdir /etc/wyng

# Write the file with vim (if you don't know vim, use nano instead)
[user@dom0 ~]$ sudo vim /etc/wyng/wyng.ini

Write the following contents to the file /etc/wyng/wyng.ini, replacing VOLUME-NAME with whatever the volume is named on the external drive you’ll be using:

[var-global-default]
dedup = 1
authmin = 10
autoprune = full
apdays = 90:7:7:1
dest = qubes://sys-usb/media/user/VOLUME-NAME/backups/laptop.backup

Extend metadata space

If you have a default Qubes OS installation, it uses a “thin-provisioned LVM” filesystem. To use Wyng safely with a default Qubes OS installation, we’ll need to triple the amount of space allocated to metadata by default, as described by the docs.

First, we need to determine what the default metadata size is. This filesystem uses two terms that you should know: the Volume Group (in our case, qubes_dom0), and the Logical Volume (in our case, vm-pool). Again, in the dom0 terminal:

[user@dom0 ~]$ sudo lvs -o+metadata_size qubes_dom0/vm-pool

This will output a value for Msize. We will use the example of 100.00m i.e. 100 megabyes. This means that we want to extend it to a total size of 300.00m.

Secondly, we need to make sure that the Volume Group has enough space for this extension:

[user@dom0 ~]$ sudo vgs

This will output a value for VFree, which should be larger than the amount of space that you want to extend by (in our example, a difference of 200 megabytes). If you need to free up space in the Volume Group before you can extend, see the instructions for taking some space from the swap logical volume.

Finally, we will do the extension:

[user@dom0 ~]$ sudo lvextend --poolmetadatasize 300.00m qubes_dom0/vm-pool

Now even during the Wyng backup, the Meta% of qubes_dom0/vm-pool shouldn’t rise about 50%.

Select qubes for backup

In Qube Manager, select all qubes that you want to be backed up by checking their “Backup” column.

Using Wyng

Plug in your external drive

Plug your external drive into the computer. Open a File Manager in the sys-usb qube, and use it to decrypt the LUKS partition of your external drive. Create a directory named backups at the root of the decrypted volume if it doesn’t already exist.

Create a fresh archive

Start by creating a fresh Wyng archive, which will prompt you for a backup password:

[user@dom0 ~]$ sudo wyng arch-init

You will see that on your external drive, a directory now exists named laptop.backup. Don’t manually alter the contents of this directory.

Backup, arch-check, monitor

Every time you do a backup, there are three important operations: prune (get rid of old unnecessary backups), make a new backup, and then verify that the backup archive isn’t corrupted.

The following command will backup every qube that was previously checked in Qube Manager. The configuration file we made earlier also prunes old backup sessions at the same time, based on the criteria we specified. For example, our choice of apdays=90:7:7:1 will cause autoprune to remove all sessions that are older than 90 days, and sessions older than 7 days will be thinned-out while preserving (roughly on average) 1 session per week. See the docs for more information.

[user@dom0 ~]$ sudo wyng-util-qubes backup --includes 

After the backup is complete, check the the integrity of the archive:

[user@dom0 ~]$ sudo wyng arch-check --session=newest

Lastly, we will free disk space used by aging snapshots:

[user@dom0 ~]$ sudo wyng monitor --all

Restore

If you would like to first list what qubes are in the archive that can be restored, run:

[user@dom0 ~]$ sudo wyng-util-qubes list --all

Before restoring a qube, if you don’t want the version currently on your system to be overwritten by the restored backup, CLONE IT BEFORE RESTORING. For the example of a qube named “personal”, first clone it with the name “personal-clone-1”, then you can restore the latest backup of “personal”:

[user@dom0 ~]$ sudo wyng-util-qubes restore personal

In contast, if you have a fresh Qubes OS installation and you’d like to restore the last session in its entirety, first do the “Set up” steps above, then simply run:

[user@dom0 ~]$ sudo wyng-util-qubes restore 

Optional: Script the backup/check/monitor

In dom0, use vim (or nano) to create the file ~/Documents/backup.sh, with the following contents:

#!/bin/bash

echo "Starting backup..."
sudo wyng-util-qubes backup --includes
echo "Starting check..."
sudo wyng arch-check --session=newest
echo "Starting monitor..."
sudo wyng monitor --all

Then make the file executable:
[user@dom0 ~]$ chmod +x ~/Documents/backup.sh

To backup/check/monitor, you can now simply run:
[user@dom0 ~]$ ~/Documents/backup.sh

I can only hope that this guide becomes irrelevant because Wyng gets used as the backend of the Qubes OS backup tool. Practically every Qubes OS user I know uses the backup tool far too rarely to be functional in the case of data loss, and it’s because people today expect something far faster, like the macOS time machine. So here are my two cents that the Qubes OS community deserves better than the current backup tool, and Wyng is a realistic amount of code to audit and throw a GUI in front of.

4 Likes

Thanks for this guide! Could you explain how to remove backups older than n days?

1 Like

From the docs linked above:

--apdays=A:B:C:D

Adjust autoprune with the following four parameters:

  • A: The oldest day before which all sessions are removed. Default is 0 (disabled).
  • B: Thinning days; the number of days before which some sessions will be removed according to the ratio D/C. Default is 62 days.
  • C: Number of days for the D/C ratio. Default is 1.
  • D: Number of sessions for the D/C ratio. Default is 2.

An example: --apdays=365:31:1:2 will cause autoprune to remove all sessions that are older than 365 days, and sessions older than 31 days will be thinned-out while preserving (roughly on average) two sessions per day.

is there a GUI for this?

No. I wrote a very crude one, but abandoned it. Scripting your backup and restore sequence and using the wyng.ini is for now the most streamlined and accessible way to use wyng.

Anyone know what this error means and how to fix it?

Qubes 4.2.3:

sudo wyng monitor --all
Wyng 0.8 beta release 20240827
Local storage is offline: None
Encrypted archive 'qubes://XXXXXXXX.backup' 
Last updated 2024-12-27 22:59:46.728995 (+00:00)

Error: Local path not found.
Offline volumes: <List of volumes>

Error on volumes: <Same list as above>

However, 'wyng arch-check --all' does not report any errors. Do I need to define a specific pool with the '--local <path>'?

@solene Hello, I am new to Linux and Qubes . I followed this guide but seems to have some errors . Do you know how I can resolve them? When I researched it lead me to this. Thanks in advance.

Qubes 4.2.3

$ cat /proc/sys/fs/protected_hardlinks
1

Here is the errors when I run Wyng.

$ ~/Documents/backup.sh
Starting backup...
wyng-util-qubes v0.9 beta rel 20240918
Enter passphrase: 

Selected for backup:
 anon-whonix, audio-app, audio-template,  debian-12-xfce, default-dvm, default-mgmt-dvm, dom0,  fedora-40-xfce,  personal, sys-audio, sys-firewall, sys-net, sys-usb,  sys-whonix, untrusted, vault, whonix-gateway-17, whonix-workstation-17, whonix-workstation-17-dvm,  work 

 Skipping default-mgmt-dvm
 Skipping dom0
Wyng 0.8 beta release 20240827
CalledProcessError(1, [['/usr/bin/qvm-run', '--no-color-stderr', '--no-color-output', '-p', 'sys-usb', '/usr/bin/sh /tmp/wyngrpc/tmp895o3qst'], ['/usr/bin/cat', '-v'], ['/usr/bin/tail', '--bytes=2000']])
/tmp/wyngrpc/tmphIxkk9w7BhJl
wyng_check_free /dev/sda1        125281344   320 125281024       1% /run/media/user/9615-9AA2
wyng_archive_ini f4c44fc3bea0293d7e76018f8425e79c0886cde12ad0e5433c57173b3ed91ed4  archive.ini
wyng_writable

ln: failed to create hard link '.hardlink' => 'archive.dat': Operation not permitted
[0, 1]

Destination not ready to receive commands.
Starting check...
Wyng 0.8 beta release 20240827
Encrypted archive 'qubes://sys-usb/run/media/user/9615-9AA2/backups/laptop.backup' 
Last updated 2025-01-05 05:30:38.859001 (-05:00)
Starting monitor...
Wyng 0.8 beta release 20240827
Local storage is offline: None
Encrypted archive 'qubes://sys-usb/run/media/user/9615-9AA2/backups/laptop.backup' 
Last updated 2025-01-05 05:30:38.859001 (-05:00)

Error: Local path not found.
Offline volumes: 


There is not much information about the destination, my first guess is that the filesystem does not support hard links. What you found in sysfs is that your kernel is capable of hard links, not that the filesystem support it (otherwise you would have a per FS entry)

1 Like

You where absolutely correct my external storage fs did not support hard links. I re formatted to one that does it solved the hard link error. I am getting what seems to be the same monitor error though . I see that the person’s post above mine has this error as well. Thank you for the replies and your time.

What is the monitor error?

$ sudo wyng monitor --all
Wyng 0.8 beta release 20240827
Enter passphrase: 
Local storage is offline: 'qubes_dom0/pool00'
Encrypted archive 'qubes://sys-usb/run/media/user/Samsung/backups/laptop.backup' 
Last updated 2025-02-02 19:22:33.579776 (-05:00)

Error: Local path not found.
Offline volumes: vm-anon-whonix-private, vm-audio-app-private,


Error on volumes: vm-anon-whonix-private, vm-audio-app-private,

This looks wrong, do you have multiple pools?

I just tested and the command works fine for me.

I only have the Qubes default installation so (1pool). If I don’t use the --local option I get he same error Local storage is offline: None

I changed the --local option path resulted in errors…

$ sudo wyng monitor --all
Wyng 0.8 beta release 20240827
Encrypted archive 'qubes://sys-usb/run/media/user/Samsung/backups/laptop.backup' 
Last updated 2025-02-02 19:22:33.579776 (-05:00)

Preparing snapshots in '/dev/qubes_dom0/'...
Warning: Local '/dev/qubes_dom0/wyng-qubes-metadata' does not exist!
Acquiring deltas.
Traceback (most recent call last):rivate
  File "/usr/local/bin/wyng", line 5115, in <module>
    monitor_send(storage, aset, vols or selected_vols, monitor_only=True)
  File "/usr/local/bin/wyng", line 3814, in monitor_send
    updated, svsize, vperms = storage.process_deltas(storage, aset, datavol, monitor_only)
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/bin/wyng", line 3184, in update_delta_digest_lvm
    assert t1 == t2
           ^^^^^^^^
AssertionError


After running last command:

sudo wyng monitor --all

I get errors after entering passphrase:

Local storage is offline: None
Encrypted archive 'qubes://sys-usb/media/backups/pc.backup'
Last updated [date/time]

Error: Local path not found.
Offline volumes: [list all volumes]

Error on volumes: [list all volumes]

Disk is still mounted in sys-usb at /media/

Been using wyng successfully to backup and restore VMs. Very quick and efficient.

I stopped using the suggested “monitor --all” since i (and others) seem to just get errors.

@tasket I have questions about best practices for verifying a wyng backup. This tutorial suggests:

I tried as an alternative:
sudo wyng-util-qubes verify --session=newest

But get an error: “No sessions match” as it apparently doesn’t recognize “newest” as an option. If I run wyng-util-qubes verify with an existing session number I get a different output and longer process than if I run wyng arch-check. So is wyng-util-qubes verify doing more? doing something different than wyng arch-check?

Which is better to use in Qubes?

And will there be an option to pass “newest” to wyng-util-qubes?

You’re right that ‘newest’ isn’t recognized in that context.

So is wyng-util-qubes verify doing more?

If you run verify and arch-check --session newest after each backup, then the difference will be that verify is re-checking much old data that has already been checked along with any new data. This is because in an incremental backup system, newer snapshots are composed of old data in the spots where there were no recent changes. The difference in the amount of checking is probably quite large. Verify asks “is this whole volume at time X valid?” while arch-check asks “is the new data added at session time X valid?”. If you want to be efficient but a little extra careful, you could do arch-check --session newest after each backup but infrequently run verify instead. Verify is like wyng receive as it receives a whole volume intact, but it doesn’t save it anywhere.

arch-check just looks at each layer in the incremental additions for that volume, starting with the newest, until it gets to the oldest entry which will of course contain an entire volume because there is nothing earlier.

Which is better to use in Qubes?

Its a matter of personal judgement, but I’d say most of the time wyng arch-check --session newest is better because it wastes less time/resources.

And will there be an option to pass “newest” to wyng-util-qubes?

Only if there’s a pressing need to use it frequently with a command like verify. I don’t think the case has been made for that yet.

I stopped using the suggested “monitor --all” since i (and others) seem to just get errors.

Recently I’ve increased the testing for monitor so I’d expect the next beta (beta12) to have fewer problems. But I should also note (and probably document) that if multiple archives are being used with the same LVM volumes then monitor may not be very useful. OTOH if you think you’re encountering a monitor bug, please do report it as an issue.

1 Like

This bug was fixed in a past Wyng release. Updating to a recent version from main or beta branch will resolve it, and it should also allow smoother operation with remote filesystems that don’t support hard links (Wyng only needs hard links when deduplication is requested by the user).

@Tee @scallyobb

I (intentionally) created my first archive on a dvm. Now i wanted to backup again using a fresh restart.
sudo wyng arch-init creates the .backup file in my destination qube.
But when running sudo wyng-util-qubes backup --includes i get this:

...
Preparing snapshots in '/dev/qubes_dom0/' ...
Skipping vm-app-audio; snapshot is from a different archive. Use --remap to clear it
Skipping vm-... // I get this for every vm now

Sendinb backup session 20250507-122749:
1.2MB | 2s | wyng-qubes-metadata
Error on volumes: vm-app-... // again for every vm

It then leaves with an RuntimeError with ErrorCode 2

No backup gets created.

I changed my destination qube, I tried deleting /var/lib/wyng Folder and some tmp files, but the issue persists.

I am not sure how to fix this now as sudo wyng-util-qubes backup --includes --remap is not possible

I had same issue: Error on new backup - snapshot is from a different archive · Issue #48 · tasket/wyng-util-qubes · GitHub

The way you do it is:
sudo wyng-util-qubes backup <qubeX> -w remap --dest=<dest>

the -w flag allows you to pass wyng options directly to wyng