Repair broken backup?


I got a problem with a backup before upgrading and was hoping that the latest beta ( would help fix it, as the repair function is improved. Unfortunately, this didn’t work.

I get this error message:

“Unexpected difference in fileset version 52: 11/23/2018 5:20:34 PM (database id: 1), found 6514 entries, but expected 6879”

I have tried “Repair” and “Delete and rebuild”. Repair have never fixed anything, rebuilding database usually fixes problems. The rebuild finish OK, but the next time the backup is run I get the same error all over again. If I delete the failing backup version, I get the same error message for the previous backup version.

Is there anything I can do to fix this, or do I have delete all versions done before the date mentioned in the error message?

Thanks, Rickard

I can add that I run Duplicati on Debian with the latest Xamarin Mono version. Everything else is running well.

Generally the best fix for this problem is to just delete the offending version. Database recreation doesn’t seem to do the trick.

Quick instructions:
Click on your backup set in the Web UI, click the Commandline link, then select “delete” from the Command dropdown. Empty the contents of the Commandline Arguments text box. Then scroll to the bottom and pick “version” from the Add Advanced Option dropdown. Enter the version number to delete (in your case: 52) and click the “Run delete command now” button.

Since you are now running the latest beta, I don’t believe you will see a new occurrence of this issue.

I have deleted a few versions already, and deleted 52 just now:
“Unexpected difference in fileset version 51: 11/24/2018 6:37:20 PM (database id: 2), found 8244 entries, but expected 8609”
I will recreate the database now and see if that makes a difference, but it hasn’t so far.

Database rebuild gives a few errors like this:

[Error-Duplicati.Library.Main.Operation.RecreateDatabaseHandler-MissingFileDetected]: Remote file referenced as by, but not found in list, registering a missing remote file

Should I delete dindex-files and rebuild again? Shouldn’t Duplicati be able to replace the data files if the files are still available, and some of the files if there are changes?

Sounds like you have something bigger going on than the typical “unexpected difference” issue we usually see in the forum.

I don’t know if deleting dindex files is the best approach, or even a good idea at all. Duplicati will regenerate them if your database is in a good state, but yours doesn’t seem to be. Have you tried that once before already?

It was the Recreate half of The REPAIR command that was improved, and most of it was performance. Major improvements were also made to Backup, and should be far less likely to break backups.

In an ideal world, perhaps so, however:


Removed automatic attempts to rebuild dblock files as it is slow and rarely finds all the missing pieces (can be enabled with --rebuild-missing-dblock-files ).

and the last time I tried that option it didn’t work. What you can attempt for missing dblock files is to run The LIST-BROKEN-FILES command and The PURGE-BROKEN-FILES command as described under Recovering by purging files which was a lab demo of recovering from an intentionally corrupted backup.

Seeing what’s broken will help decide what to do. If you’re lucky, it will be non-essential versions or files.


Sorry for the silence, I was experimenting with rebuilds that take their time. The reason for the strange DB behaviour is that the backup broke with the previous Beta, and I usually managed to repair backups by deleting problem files and then rebuilding the database. This didn’t work in this case, and that caused the imbalance in the backend.

I managed to get it all going again, deleting backup versions made the file differences decrease, and after having deleted around half of the versions it seems to be working all right.

Hopefully the new release will be more stable. Thanks for your tips and help! :slight_smile:


1 Like