Canary releases are testing releases. Problems should be reported to allow fixes.
Please check for existing reports of course. Thanks for this report. Cause may be:
which went into 2.1.0.109 and seems to have some time zone confusion. I can do:
in the UTC-4 timezone, and have Repair say:
The remote files are newer (3/12/2025 2:30:00 PM) than the local database (3/12/2025 10:30:00 AM), this is likely because the database is outdated. Consider deleting the local database and run the repair operation again.
Remote file times are 4 hours ahead, likely due to UTC. Local 2:30 isn’t here yet.
I’m not sure what time zone the unit tests run in, e.g. UTC+1 might not see this…
EDIT 1:
I’m not certain about this (need developer help), but the Canary and Beta releases lack some of the urgent fixes that led to 2.1.0.5 Stable. Not sure if that will be fixed.
C:\Duplicati\duplicati-2.1.0.110_canary_2025-02-28-win-x64-gui>Duplicati.CommandLine help read-write-timeout
--read-write-timeout (Timespan): Set the read/write timeout for the connection
The read/write timeout is the maximum amount of time to wait for any activity during a transfer. If no activity is detected for this period, the connection is considered broken and the transfer is
aborted. Set to 0s to disabled
* default value: 30s
has caused silent upload failures. 2.1.0.5 set that to a larger time (but not disabled):
Possibly a manual config (maybe in Settings, to be a default for all jobs) would help.
As for putting you backup back together, Repair will probably be willing to run when its time confusion ends, but it might not help. You can try to find what variety of files are missing with About → Show log → Live → Warning and click on Verify files. Timeouts (if that’s the issue) are probably unfortunately more likely on dblock files.
is me hitting the timeout problem on 2.1.0.107. I do have some ideas on recovering, and might try them soon (getting tired of downtime). If they work, maybe you can try.