Non-empty blocksets with no associated blocks

Hi Duplicati developers team,

yes, it seams that I am not alone:

However, what I see seems to be different.

SW-Version: Duplicati -

This is the export of my Duplicati job: (1.2 KB).

I run the Server Component as a Windows Service as described.

Every time I start a new backup it works perfectly fine, taking about 10h or so. Every second time I run the script I get the error message above.

Any ideas about a reason or a fix? Is there anything I can do to provide further details or logs? Please advise.

Thanks & many regards for the cool software!

Looks like this might be a problem within my Windows installation. Noticed also several other issues in the context of saving images, system repair can not repair the system:

sfc /scannow => Der Windows-Ressourcenschutz hat beschädigte Dateien gefunden, die teilweise nicht repariert werden konnten.

dism /Online /Cleanup-Image /ScanHealth => sticks at 100%, does not provide a result

Upgrade to Win 10 1903 did not fix this today.

Probalby sooner or later a new install from scratch will be needed… Thanks anyway.

Welcome to the forum @DBL

I’m sorry to hear about your Windows woes. I don’t know if you’re inclined to worry about Duplicati now. If you are, then Warning: sqlite-journal errors 1400 was possibly a similar problem (except maybe easier to identify) where a file being actively changed during backup triggers that problem, and possibly also yours.

If you happen to have specially installed as a Windows service (or are otherwise running on Administrator privileges), –snapshot-policy=Required would prevent Duplicati backing up Duplicati’s database while it’s actively changing. Another option to avoid that would be to Edit in an exclude Filter for files beginning with your backup’s Database path. This will avoid the .sqlite-journal file that often seems to be the culprit. Commonly the DB isn’t intentionally backed up, but just gets backed up in wholesale backups, e.g. of C:\

Because above is a guess, logs such as default backup log, or live log at About --> Show log --> Live, or setting –logfile might catch some other message or path that would help to figure out what the issue was.

Even better (if you’re willing to take a small risk of filenames being seen), is linking a database bug report.

FoundIssue1400Error took a DB-level look at that, and
CheckingErrorsForIssue1400 and FoundIssue1400Error test case, analysis, and proposal #3868 testing and theory suggests that these two issues are related.