This worked! Thanks.
I was using this command line to make a backup, and prune hold backups
sudo wyng-util-qubes --autoprune=on -w apdays=60:31:1:2 --dest=qubes-ssh://$qube:$dest -d backup -i
But using list --all it doesn’t seem to prune?
fedora-41:
20241118-183326 20241129-125932 20241215-132450 20250108-100110 20250114-104912 20250306-071412 20250416-170623 20250530-182329
20241118-212619 20241129-135534 20241218-100143 20250108-100925 20250122-093832 20250407-110723 20250428-111742 20250622-193555
20241126-091242 20241203-085537 20250107-192842 20250110-092523 20250212-114744 20250407-120251 20250524-194410
What am I doing wrong?
The autoprune section of the Wyng documentation mentions the following for the on mode:
on removes some sessions, as space is needed on the destination.
From what I understand, it only triggers when the destination is out of space.
Maybe full is what you are looking for?
Indeed, I certainly need to use full here, good catch. However, now I wonder if the “as space is needed” is something configurable. It’s actually nice to backup as much as possible, but I’d like to keep some room on the destination server, and not just room for next backup.
1 Like
Update: There are new beta releases for both Wyng and wyng-util-qubes. Among other enhancements and fixes, this release fixes a serious bug in receive/restore that can occur when a snapshot is present and an older session is selected. Updating is highly recommended.
The recent changes also add Qubes 4.3 support, but shouldn’t have any impact on the information in this guide. However, you may want to have a look at the revised docs anyway; detailed Wyng usage info has been moved into doc/Wyng_User_Reference.md.
Also, thanks to everyone who’ve been contributing their testing and feedback to make Wyng a better backup system! 
6 Likes
On R4.3 when running “sudo wyng monitor --all” i get this:
Local storage is offline: None
Wyng 0.8 beta release 20250824
Local storage is offline: None
Encrypted archive: 'qubes://<my_path>'
Last updated <date>
Error, Local path not found (None) None
Error on volumes: <my vms>
Anybody know why this might be happening?
Hello, thank you for this reply it resolved my error.
(Suddenly, everyone is interested in monitor 
)
@monoxide059 You have to specify --local for many Wyng commands. See Wyng: how to run wyng monitor…
1 Like
Couple questions:
How can I include the home dir of dom0? I have a copy of all important config files in itsolved (tar archive)How can easily I backup all VMs not just the selected ones ( -i ) ?solved (qvm-ls)Do I need to pay special attention / do things differently when using multiple different drives / destinations with different histories / timestamps ?solved I think the only thing is that --remap is needed when lvm is used?- The crypto is good enough to put on an unencrypted drive right?
Also what about cloud storage? Won’t uploading break the hard links / the whole backup or will it just increase the disk space used?
Yes. In doubt: encrypt the usb stick itself with luks.
Not sure what your question really is. Everything get stored on the usb stick / in the cloud, so there are no symlinks to outside the backup
Wyng requires hard links, the underlying storage requires support for it. It’s not always possible with a FUSE drive.
1 Like
Interesting, thanks for the information
I made some experiments a few months ago Feature Request: S3 storage bucket support · Issue #91 · tasket/wyng-backup · GitHub
So what if I upload a copy of the archive and don’t directly use the cloud? If the upload succeeds does it matter that de duplication was used or will the backup then break when trying to restore?
It can work if you wrap wyng repo directory in a tarball and untar when you need it. Although it’s not practical nor efficient, it works. At this point, consider using the current backup tool optimized with zstd to gain some time.
Wyng create millions of files, it takes time to make a tarball of this, depending of your storage.
@tasket Hello, I know your busy I appreciate when you can look at this. I was trying to restore from my backup after a unsuccessful inplace upgrade from 4.2.4 to 4.3
The restore seems to be going well until it gets to restoring vm settings of the sys-net. Wyng 0.8 rc1 release 20250904
sys-net
Traceback (most recent call last):
File "/usr/local/bin/wyng-util-qubes", line 913, in <module>
elif action == "restore": wq_context.restore()
^^^^^^^^^^^^^^^^^^^^
File "/usr/local/bin/wyng-util-qubes", line 810, in restore
res = _do_restore(self, selected=vms, session=session) ; self.close()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/bin/wyng-util-qubes", line 527, in _do_restore
assig = DevAssg.new(backend_domain=live_qubes[backend], port_id=ident,
^^^^^^^^^^^
AttributeError: type object 'DeviceAssignment' has no attribute 'new'
No that important but when creating a new archive the first time you use “backup” this error occurs:
Error
Traceback (most recent call last):
File “/usr/local/bin/wyng”, line 5945, in
raise e
File “/usr/local/bin/wyng”, line 5781, in
sid, ses_tags = monitor_send(storage, aset, vols or selected_vols, monitor_only=False,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/bin/wyng”, line 4261, in monitor_send
= storage.prep_snapshots(storage, aset, datavols, monitor_only, other_vols=imports)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/local/bin/wyng”, line 3363, in prepare_snapshots_lvm
l_vol = lvols[datavol] ; snap1, snap2 = l_vol.snap1, l_vol.snap2
~~~~~^^^^^^^^^
KeyError: ‘wyng-qubes-metadata’
Wyng::Failed return code 1
Every run after that is fine?
So breaking the hard links does not matter? Will try to use rclone with the additional encryption layer
No, you should not break the hard links, if you make a tarball of the repo it should keep hard links.