I think it’s a Canary bug which should be fixed properly. It’s good that you came across it.
Does this theory of retries possibly explain your case? Your job Complete log has stats:
"RetryAttempts": 2
is from the test I cited. It might just be a false alarm that can be overridden as shown.
This looks like another new Canary addition from almost two months ago. Issue says:
Added repair code that can handle cases where a filest or remote dlist entry is missing, and then recreates the contents.
and we’ll see if the dev has anything more to add or ask. It sounds like fixup is automatic.
I wonder if an “off by 4 seconds” message is related to “4 volumes with missing filesets”, which could happen if all the retries (named 1 second apart) somehow got on destination.
There’s supposed to be a cleanup of the uploads that got errors, deleting the failed ones.
You could see what you see on your destination around that time (dlist times are in UTC).
You might be misunderstanding The TEST command. You got 1 set (3 files), the default.
Did you try asking for more, or all?
EDIT:
CLI help test:
Usage: Duplicati.CommandLine.exe test <storage-URL> <samples> [<options>]
Verifies integrity of a backup. A random sample of dlist, dindex, dblock
files is downloaded, decrypted and the content is checked against
recorded size values and data hashes. <samples> specifies the number of
samples to be tested. If "all" is specified, all files in the backup
will be tested. This is a rolling check, i.e. when executed another time
different samples are verified than in the first run. A sample consists
of 1 dlist, 1 dindex, 1 dblock.