This message keeps showing up. If I repair the database, it will go away for a while, but then it comes back. The file is quite large (279GB), but I don’t see why that would affect the database. There is a slightly larger file in the same directory, and it never shows up as a problem.
Error message:
Found inconsistency in the following files while validating database:
W:\Videos\uvs160611-002.AVI, actual size 285629129728, dbsize 285629027328, blocksetid: 286335
. Run repair to fix it.
This error means that the file that was backed up doesn’t match the source file. What version of Duplicati are you using, where are you backing up from and to? Also have your tried restoring the file to a different directory and run a SHA-256 hash against the restored file and the file in the source? If they don’t match try changing the job settings to add the “disable-filetime-check” option. Run the backup again, however it will run longer as Duplicati will hash all the files again. Let me know what happens.
After you try the restore and verify that the files are different, try to change the settings on a single run with adding the option I suggested. If the error no longer appears you can remove that option.
@bkuehner, I noticed you opened another thread on issues with your SQLite database. They could be related, but it appears you have may have issues with the disk that holds your database.
I’m pretty sure that isn’t an issue here, because I’d expect other file corruption to be evident. I have 10 backup jobs running with database stored on the same drive, and only those two every show a problem. I will run a chkdsk on it, but I’d be very surprised. I can open the SQLite database and peruse it with no problems.
I’m wondering if the subst has something to do with it, because only the backups from those “virtual” drive letters have this issue.
Also check the Windows System Event log for disk related errors. If the disk is fine, maybe just alter the job to backup directly from the location rather than using subst to create a drive letter. While I don’t think subst itself would be causing an error, it may get a bit fiddly if you’re jobs use VSS. May I ask the reason why you’ve chosen to backup from a virtual drive rather than from a directory itself?
No disk errors in the event log.
That’s a fair question about using the subst-ed drive. I set it up that way to match the path that all other file access uses for those files, but there is no particular reason the backups can’t use the real path.
I will give that a try.
I’m using whatever the default VSS options are, which I think is set to not do a snapshot prior to backup, is that correct?
The other backup failure I’m having (in the other thread) does not use a subst-ed path, so it will still be an issue even if this one is fixed.
Yeah, just change the job to point to the directory. Duplicati should do a regular incremental as the files and hashes are already in the database.
The default VSS option is “Auto”. It will attempt to do a VSS snapshot and fail silently if it can’t. So it doesn’t produce an error on failure, but still attempts it. If you don’t need VSS then disable it.
