search

tasket / wyng-util-qubes

Qubes integration for Wyng enables backup and restore by VM name
GNU General Public License v3.0
8 stars 2 forks source link

[feature request] Update qubes date of backup #33

Open rapenne-s opened 2 weeks ago

rapenne-s commented 2 weeks ago

Hi

It would be nice if wyng-util-qubes could update the metadata backup_timestamp of each qube after a successful backup. This information is shown in qubes manager, and I'm writing a script to display a notification when last backup is too old, but wyng does not update this field

tasket commented 1 week ago

OK this feature is now in the wip branch!

kennethrrosen commented 1 week ago

Just tested. Even for VMs with 0.0MB change, it took quite a while, which I don't think is a product of the update/feature. But the error message below did occur. SOCKS5-proxy is listed in my script as a VM to backup, but does not exist. A backup I ran yesterday simply alerted Skipping SOCKS5-proxy and then no other error message.

Most crucially, Qube Manager only displays "Last backup" as those backed up using the qvm-backup tool. backup_timestamp metadata for one of the qubes merely shows 1723542128 and in Qube manager 2024-08-13 05:42:08

Traceback (most recent call last):
  File "/usr/bin/wyng-util-qubes", line 323, in <module>
    for vm in (live_qubes[x] for x in to_backup if x not in ("dom0","default-mgmt-dvm")
  File "/usr/bin/wyng-util-qubes", line 323, in <genexpr>
    for vm in (live_qubes[x] for x in to_backup if x not in ("dom0","default-mgmt-dvm")
               ~~~~~~~~~~^^^
  File "/usr/lib/python3.11/site-packages/qubesadmin/app.py", line 109, in __getitem__
    raise KeyError(item)
KeyError: 'SOCKS5-proxy'
tasket commented 1 week ago

@kennethrrosen

Even for VMs with 0.0MB change, it took quite a while,

If it says "0.0 MB" sent for a volume and it took a while, it could mean the snapshot became un-paired or deleted (in which case Wyng will show a message like "Removed mis-matched snapshot..."). It could also mean that the volume was manipulated/rewritten to a large extent but ended up with the same data contents as the prior backup (sounds odd, but it can happen). There's another possibility I'd like to test for zero- or near-zero conditions but that will be an issue in Wyng itself.

Qube Manager only displays "Last backup" as those backed up using the qvm-backup tool.

It won't update the VM timestamp if an un-handled error occurs. I'll post a fix to avoid the problem.