I just got hit by this on one system. I know it’s over loaded system, and there might be reasons why it’s likely to get “any issues” if the logic is broken on some level. Ie. race conditions etc. I updated to latest version. Tried repair, didn’t work out. Saved the full old backup set and then did full reset. I did save backup files and database, if some extra information is necessary. I also updated to latest beta hoping that the source of this issue has been fixed in it.
Just hoping that the true root cause for this is known and fixed.
System.Data.ConstraintException: Detected 7 file(s) in FilesetEntry without corresponding FileLookup entry at Duplicati.Library.Main.Database.LocalDatabase.RemoveRemoteVolumes(IEnumerable1 names, IDbTransaction transaction) at Duplicati.Library.Main.Operation.FilelistProcessor.RemoteListAnalysis(IBackendManager backendManager, Options options, LocalDatabase database, IDbTransaction transaction, IBackendWriter log, IEnumerable1 protectedFiles, IEnumerable1 strictExcemptFiles, VerifyMode verifyMode) at Duplicati.Library.Main.Operation.FilelistProcessor.VerifyRemoteList(IBackendManager backend, Options options, LocalDatabase database, IDbTransaction transaction, IBackendWriter log, IEnumerable1 protectedFiles, IEnumerable1 strictExcemptFiles, Boolean logErrors, VerifyMode verifyMode) at Duplicati.Library.Main.Operation.BackupHandler.PreBackupVerify(Options options, BackupResults result, IBackendManager backendManager) at Duplicati.Library.Main.Operation.BackupHandler.RunAsync(String sources, IBackendManager backendManager, IFilter filter) at Duplicati.Library.Main.Controller.<>c__DisplayClass22_0.<b__0>d.MoveNext() — End of stack trace from previous location — at Duplicati.Library.Utility.Utility.Await(Task task) at Duplicati.Library.Main.Controller.RunAction[T](T result, String& paths, IFilter& filter, Func3 method)
Unfortunately I didn’t find anything deeply solid, what would be really helpful.
From the logs I was unfortunately unable to figure out exactly where it happened (initial case). It might have been that the run has been terminated as example while compacting.
But based on the evidence trail it seemed like something following. It was deleting seven files from the server. The repair tried to delete the seven files, but still crashed with that FilesetEntry error.
There’s no problem with the host, there’s no problem with the client.Both are technically good. The SQLite database was transitionally solid, no problem with it either (test_integrity). All our hardware is enterprise stuff. No other issues have been detected with databases, or other larger hashed / signed / encrypted data sets.
I also did run full restore from the backup data files after deleting the database, and it worked as expected restoring last full version. So this is not nearly as bad as the some earlier cases were. But the actual problem it causes, that further backup runs will fail, until manual fix operation is done. The backup from files set restored successfully to latest version, which is of course important.
I still could imagine situations where users assume that backups are running, even if this issue would prevent backup jobs from running.
My best guess is that very slow compaction job was once again more or less forcefully stopped by scheduled (graceful!) system reboot. Yes, that happens with my current environment from time to time. - It shouldn’t mess up anything that works transitionally and designed to operate safely in case of even hard faults.
Unfortunately in this case the filenames/paths contain PII, so I can’t share the whole database as I’ve done sometimes earlier when there’s just random hex filenames in the dataset or dbdump.sql or data.zip or something like that in the archive.
So details for possible bug ticket would be unfortunately quite slim.
Hey! Based on kenkend k’s (intentionally unlinked) request, could you send the database (not the backup files) for analysis to? I’m prepared to do that next time if that happens with any of my normal systems, which do have “generic filenames”. If you check logs, did it trigger after or during compaction? I assume that normal “add to backup” doesn’t cause that problem. At least in my log it was after compaction was running while the system rebooted based on schedule. → Transactional issue on updates of the database content. And no, I don’t dare to say it would be database problem, because it’s more likely how the transactions are triggered and used.
Hi, unfortunately I have already used “Delete and recreate” for local database.
Section Home / Reporting / Show log / General - is empty now (database recreation in progress)
Created bugreport doesn’t seem to be doing anything
interface http://127.0.0.1:8200/ngax/index.html#/
I am not sure how to switch back to the new interface
I see log in About / Show Log / Stored
content as displayed in my previous message
I just encountered the same issue (“Detected 80 file(s) in FilesetEntry without corresponding FileLookup entry” in my case) in 2.2.0.3_stable_2026-01-06. It occurred after Duplicati seemingly crashed during a running backup (the backup was running, then suddenly the tray icon disappeared and the Web GUI displayed message “can not connect to server”).
I will PM you the bug report. I hope it helps you figure out what was wrong and how to become more resilient against similar failures going forward.
My previous backups ran without a problem. Then one day, I made the next (automatic) backup and was greeted by this error message: 2026-01-31 18:16:43 +01 - [Error-Duplicati.Library.Main.Operation.BackupHandler-FatalError]: Fatal error FileNotFoundException: Could not find file '\\?\C:\Users\dpstef\AppData\Local\Mozilla\Firefox\Profiles\[...].default-[...]\cache2\entries\[...]'. and a failed backup.
I excluded this directory and re-ran the backup manually. Then after just 12 minutes it failed with this error: 2026-01-31 18:38:43 +01 - [Error-Duplicati.Library.Main.Controller-FailedOperation]: The operation Backup has failed ConstraintException: Detected 20 file(s) in FilesetEntry without corresponding FileLookup entry
I’m also on 2.2.0.3_stable_2026-01-06 but never had a problem with this directory in earlier backups (most probably with earlier versions of Duplicati). This backup runs on a weekly schedule and has 11 versions up to now.