Thanks for your input!
For the record, that folder also contains a Python version of the script for those not running Windows. 
To what did you rename the file?
After getting a tip to check the live logs, this finally helped me get this resolved. I renamed the aes file, ran the repair and the next backup was successful. Will know for sure later tonight when it runs on the schedule.
I get the same error on 2.0.5.110_canary_2020-08-10 on Win10. The backup runs fine once, then the next day I get the error. After a reboot, the backup runs fine again the day after, then error on the following day. Reboot, fine, error, and so onā¦
Edit: In the meantime, Iāll just have del "C:\Users\USER\AppData\Local\Temp\dup-*" /f /q run after the backup.
If āsame errorā means that your job log shows an error in Verifications, note the earlier description that the temporary files are the downloaded name of the earlier-mentioned destination file, and its name varies.
Actually the chosen backup file also varies, and possibly that explains some variability in success/failureā¦
Cleaning up the temp files might not help, but I guess weāll see. You might have a downloading problem, or actual broken files at the destination. If you like, you can force a test of all backup files with Commandline.
Another method would be to download the problem file somehow, then see if you can unzip it successfully, or (if encrypted), decrypt it using GUI AES Crypt, or Duplicatiās included SharpAESCrypt.exe CLI program.