Abort due to constraint violation

Can anyone tell me what all this means? I’ve filtered this file (and another similar one) out of the backup plan, but I still get daily errors.

Failed to process path: /home/user/filename.sh

Mono.Data.Sqlite.SqliteException: Abort due to constraint violation

UNIQUE constraint failed: FilesetEntry.FilesetID, FilesetEntry.FileID
at Mono.Data.Sqlite.SQLite3.Reset (Mono.Data.Sqlite.SqliteStatement stmt) <0x416a7070 + 0x00243> in :0
at Mono.Data.Sqlite.SQLite3.Step (Mono.Data.Sqlite.SqliteStatement stmt) <0x416a6c40 + 0x00132> in :0
at Mono.Data.Sqlite.SqliteDataReader.NextResult () <0x416a4b50 + 0x0054f> in :0
at Mono.Data.Sqlite.SqliteDataReader…ctor (Mono.Data.Sqlite.SqliteCommand cmd, CommandBehavior behave) <0x416a48e0 + 0x00144> in :0
at (wrapper remoting-invoke-with-check) Mono.Data.Sqlite.SqliteDataReader:.ctor (Mono.Data.Sqlite.SqliteCommand,System.Data.CommandBehavior)
at Mono.Data.Sqlite.SqliteCommand.ExecuteReader (CommandBehavior behavior) <0x416a3e20 + 0x0003f> in :0
at Mono.Data.Sqlite.SqliteCommand.ExecuteNonQuery () <0x416a3d70 + 0x00023> in :0
at Duplicati.Library.Main.Database.LocalBackupDatabase.AddUnmodifiedFile (Int64 fileid, DateTime lastmodified, IDbTransaction transaction) <0x41915790 + 0x000cd> in :0
at Duplicati.Library.Main.Operation.BackupHandler.AddUnmodifiedFile (Int64 oldId, DateTime lastModified) <0x41915740 + 0x00033> in :0
at Duplicati.Library.Main.Operation.BackupHandler.HandleFilesystemEntry (ISnapshotService snapshot, Duplicati.Library.Main.BackendManager backend, System.String path, FileAttributes attributes) <0x4190db50 + 0x01ddf> in :0

Hello @Edwin_Humphries and welcome to the forum!

What version are you running? There was a fix for a similar error at UNIQUE constraint failed with SIA (Support Request) [2.0.3.6], however that seemed more like a Windows problem with VSS on, and yours appears Linux. Possibly there’s a chance that the same change will have benefits in other situations. The error is basically the SQLite database saying Duplicati tried to add something already there. SQL databases often have constraints.

Hi @ts678

I’m running Duplicati - 2.0.3.3_beta_2018-04-02, which is the Linux-Mint repo’s version.
Is what you’re saying that I just have to put up with it? It’ll be the boy who cried wolf: I see errors every day, so when something serious happens, I won’t recognise it straight away.
I guess part of my whinge is that the error messages are not particularly useful for non-programmers to debug.

People can also download Duplicati from https://www.duplicati.com/download, however there’s no beta newer than 2.0.3.3 now, though there’s been a push to get one out (but I don’t know when that will actually happen). There’s also a chance that your error is different, and I don’t know how to tell without testing the fixed version. Problem with trying it is that canary stability varies, and some people don’t prefer the newest fixes (and bugs).

Regarding error messages, expected ones are the best phrased, and unexpected ones are tough to explain. Unfortunately there are still a lot of stack traces shown, but that information can be helpful to the developers. This exact situation doesn’t seem to have been reported before, so I’m pointing at something similar-looking. Typically people report an intermittent problem. Yours seems solid. Did it always do these or start sometime?

If getting to a current canary build to see if it helps doesn’t suit you, I suppose there is a chance that using a Database management operation such as Repair (but make sure you’re not running two copies of Duplicati) or Delete (local database only, definitely not destination files which are the backup) then Recreate will help, although messing with databases can be risky itself, and Recreate can be slow (especially on big backups).

Are you using a –snapshot-policy? I had forgotten that it’s not only Windows VSS. Linux snapshots with LVM. Processing files which are not in backup sources was (as I understand it, which is far from completely) also a cause of files being processed twice, causing the database to complain about that (which shouldn’t happen).

You mention “another similar one”. Is it similar in that it gets these errors, or similar in some clue-giving way? Although you might not want to keep it this way forever, does the problem follow the files if they’re relocated?

Sorry about the noise. I notice another change was to make this a warning. The duplicated Insert did nothing.