I have one backup job where Duplicati always shows:
Last successful backup:Yesterday at 9:00 PM (took 00:00:03)Run now
Next scheduled run:Today at 9:00 PM
Source:0 bytes
Backup:0 bytes / 0 Versions
It’s a backup from a server to a client machine, and the client machine is often offline (sleeping). So I might expect the “Source” to read 0 bytes if it can’t connect, but why does it show 0 versions when it has 3 saved, and I’ve successfully restored from the backups? The sqlite database is present, and is 180MB. Nothing seems wrong other than Duplicati saying 0 bytes/0 versions, so I hope this is just a “cosmetic” error but I’m not sure.
I’ve done a full test command with:
all
--full-remote-verification=true
everything turned out OK, and I’ve tried logging out and back in again, but it still says the same thing. Has anyone else seen/solved this? The sqlite database is owned by root:root just like all the others in /usr/lib/duplicati/data.
I was able to replicate this by using --run-script-before and having the script exit with errorlevel 1. Is that what you’re doing by chance? You have a script that detects when the machine is offline so the backup job doesn’t run?
Thanks for finding and linking the issue. Referencing them updates them so sort by recently updated will see that it’s not one of the too-many inactive (and sometimes hard-to-fathom) issues, but a current readable one.
This doesn’t guarantee action, but at least it gives hints to development on some potentially good candidates.
where can I find a reference to the handling by Duplicati of the exit codes from before- and after-run scripts?
It feels like folklore, in these conversations.
If it’s comments in code somewhere just tell me which module to go read. Not that it shouldn’t be documented in actual documentation, but code-comments is better than nothing