--log-retention = 30D
Set the time after which log data will be purged from the database.
The default –log-retention might explain that, however what’s gone is gone unless you saved the information somehow, for example by using reporting options, your own –log-file, or DB backups.
On that note, please do not attempt to Recreate or Repair the DB until it’s found whether you got damaged dlist files. They can be rebuilt from the DB if needed, but only if the DB has the old info.
Before starting there, do you ever throttle the upload or download speed by advanced options or through use of the throttle controls at the top of the web UI screen (to the right of the status bar)?
You can get a second opinion on your dlist files in a couple of ways. One simple one not involving Duplicati at all is to download from OneDrive then see if AES Crypt can decrypt them successfully.
Same thing can be done with Duplicati’s included SharpAESCrypt.exe command if you prefer CLI.
Decrypt failure probably means damage (somehow). If it decrypted, feel free to peek at filelist.json, which is the map to your backup, which is why I don’t want you to lose these, or the backup is lost.
If you’d rather have Duplicati web UI do the work, you can open another tab to do direct restore to determine whether it can read your dlist files. Copy parameters from backup tab, or other records. Getting as far as being able to see the contents of the questionable backups means dlist read OK.
I’m not sure what shape your other files are in. The automatic verification sample after backup will include dindex and dblock files as well, however since all I see so far are dlist, let’s start with them. Heavy sampling for file integrity test is possible, all the way up to all your 180 GB, but let’s hold off.