This is confusing because topic title gave one issue, but original post was different. Now a third.
“Detected non-empty blocksets with no” is suggestive of bug CheckingErrorsForIssue1400 and FoundIssue1400Error test case, analysis, and proposal #3868 fixed in Fix for issue1400 #3872
Quota warning looks like v2.0.2.18-2.0.2.18_canary_2018-02-11 and was meant to be a feature:
Added warnings when the backup is nearing the quota limit, thanks @tygill
The manual seemingly hasn’t caught up, but program’s help text shows this configuration option:
C:\Program Files\Duplicati 2>Duplicati.CommandLine.exe help quota-warning-threshold
--quota-warning-threshold (Integer): Threshold for warning about low quota
Sets a threshold for when to warn about the backend quota being nearly
exceeded. It is given as a percentage, and a warning is generated if the
amount of available quota is less that this percentage of the total
backup size. If the backend does not report the quota information, this
value will be ignored
* default value: 10
C:\Program Files\Duplicati 2>
The GUI also has it on the Options screen Advanced options. Basically, your destination is almost full. How you solve that depends on your destination type (what is it?), willingness to expand your storage, and so on. To lower Duplicati use is possible but awkward. Backend quota is close to being exceeded
The third issue has some similarity to “Unexpected difference in fileset” test case and code clue #3800 which is also fixed but not in any beta yet. Knowing whether or not you got a compact leading up to the 6.10.2019. 10:18:13 version would be possible by looking at CompactResults in an email report, or backup job log, but the backup job logs are in the backup job database, so Recreate may lose the logs.
Historically one recovery from “Unexpected difference in fileset” is to try delete of that version, but issue sometimes then shows up on another version. First version that fails during test is the one that’s named.
Your issue showing up in an old version would hint at the compact bug, because dblock files from older versions are more likely to have wasted space. Unless you keep all versions forever, change obsoletes data from older versions, so compact runs and then has the potential to lose track of some data block…
Turning on –no-auto-compact can avoid the compact bug in the future, until you can get a fixed release. Cleaning up damage from the bug is limited by available tools. If you’re SQL-expert, other ways may fit.